GitLab, Postgresql und VServer Probleme

Nach einigen Arbeiten an einem VServer, brauchte dieser einen Reboot. Und wie sollte es anders sein, danach wollte GitLab nicht mehr korrekt starten.

Ohne mich zunächst groß um die Gründe dafür zu kümmern, packte ich die Gelegenheit beim Schopfe und dachte mir, ich gönne GitLab mal ein Update. Ich hätte es besser wissen müssen, denn ich hab noch nie ein reibungsloses GitLab-Update vollziehen können…

Das Problem

Auch nach dem Aktualisieren von GitLab ließ es sich nicht dazu bewegen, sich in Gang zu setzen. Irgendwie lief ein Subset der nötigen Prozesse, so dass ich im Browser mal einen Error 502, mal einen Error 500 bekam.

Das Ganze hatte mit Postgresql und dem VServer zu tun, aber der Reihe nach:

Aktualisieren von GitLab unter Ubuntu 14.04

Fangen wir doch bei Schritt eins an und sorgen erst einmal dafür, dass GitLab wieder aktuell ist. Dazu benutze ich unter Ubuntu inzwischen fertige Pakete.

Mit zwei Zeilen auf der Konsole, und alles ist recht schnell installiert. Ratsam ist es, vorher die alte GitLab Instanz zu stoppen sudo service gitlab stop oder sudo gitlab-ctl stop, je nach Version.

Dann kann die Installation losgehen:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

Nicht wundern, zunächst wird das Paket gitlab deinstalliert, es wird durch das neue gitlab-ce ersetzt. Es laufen einige Informationen den Screen lang. Beim ersten Versuch bekam ich einen Fehler und das Paket konnte nicht vollständig installiert werden. Fragt nicht warum, aber beim zweiten Anlauf klappte es.

Danach nur noch einmal GitLab rekonfigurieren, damit die alte Einstellungen übetragen werden:

sudo gitlab-ctl reconfigure

Fertig! Oder?

Error 502 - Postgresql zum Laufen bewegen

Nach der Installation bekam ich den besagten Error 502. Ein Blick auf gitlab-ctl status verriet mir, dass eigentlich alles wunderbar läuft.

Um ganz sicher zu gehen, ließ ich GitLab mal einen Selbsttest machen:

sudo gitlab-rake gitlab:app:check

Zunächst sah es ganz gut aus, doch dann brach der Test ab. Auf Postgresql konnte nicht zugeriffen werden, weil unter /tmp keine Socket gefunden wurde. Nach einigem Suche und den Hinweisen, man solle doch einen Symlink erstellen, stieß ich auf das eigentliche Problem.

Postgresql, VServer und der RAM

Scheinbar ist Postgresql standardmäßig so konfiguriert, dass es versucht sich 25% RAM zu reservieren. Was auf VServern schief laufen kann. Ein Blick ins Logfile (/var/log/gitlab/postgresql/current) legte etwas in der Art nahe. Also ab in die GitLab-Config.

GitLab kommt mit einer eigenen Postgresql-Instanz daher und auch mit einer eigenen Config und zwar die zentrale GitLab-Config unter /etc/gitlab/gitlab.rb.

Laut Dokumenation von GitLab sollte man dort postgresql['shared_buffers'] = "100MB" setzen. Das tat ich und Postgresql tat es weiterhin nicht. Die Logausgabe meckerte immer shmmax an. Also mal in der Config geschaut und einen entsprechenden Wert (auskommentiert) gefunden. Ich setzte diesen Wert dann auch noch mal runter: postgresql['shmmax'] = 10179869184

Daraufhin habe ich GitLab wieder rekonfigurieren lassen

sudo gitlab-ctl reconfigure

Und dann auch noch einmal neugestartet, damit Postgresql auch wirklich mitspielt.

sudo gitlab-ctl restart

Ein Blick auf /tmp erfreute mich dann mit der Anwesenheit einer Socket-Datei. Wunderbar. Den Browser aufgerufen und anstatt eines Error 502 nun ein Error 500.

Error 500

Da jetzt alle Dienste laufen, starte ich noch einmal den Selbsttest, in der Hoffnung, diesmal ein wenig mehr Informationen zu bekommen.

sudo gitlab-rake gitlab:app:check

Und siehe da! Die Datenbank muss noch migriert werden.

sudo gitlab-rake db:migrate RAILS_ENV=production

Ein weiterer Test bestätigte, alles grün. Also noch einmal GitLab restarten:

sudo gitlab-ctl restart

Ein Blick in den Browser und es wird ein Loginscreen präsentiert. Auch via Git lässt sich nun wieder pullen und pushen.

Wollen wir hoffen, dass das nächste Update dann etwas entspannter läuft.

Update

Nach einem Server-Restart, bestand das Problem wieder. Wahnsinn. Folgender Beitrag half aber.

Quellen:

https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master#postgres-error-39-fatal-could-not-create-shared-memory-segment-cannot-allocate-memory-39

https://gitlab.com/gitlab-org/gitlab-ce/issues/719

0
0
blog comments powered by Disqus