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-ceNicht 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 reconfigureFertig! 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:checkZunä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 reconfigureUnd dann auch noch einmal neugestartet, damit Postgresql auch wirklich mitspielt.
sudo gitlab-ctl restartEin 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:checkUnd siehe da! Die Datenbank muss noch migriert werden.
sudo gitlab-rake db:migrate RAILS_ENV=productionEin weiterer Test bestätigte, alles grün. Also noch einmal GitLab restarten:
sudo gitlab-ctl restartEin 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.