Eigentlich ist das nächste kuerbis.org Weekly längst überfällig, aber da es zum einen letzte Woche außer der NoSQL Usergroup Cologne nicht viel gab, was mich hätte zum Schreiben veranlassen können, und zum anderen ich mich seit ebenfalls letzter Woche mit einer Erkältung / einem grippalen Infekt herum schlage (Grippe haben mein Arzt und ich einstimmig ausgeschlossen, und momentan sieht es auch danach aus, als ob ich als Sieger aus dem Kampf heraus gehe), folgt heute mal wieder ein kürzerer Beitrag. Über das NoSQL UG Treffen werde ich vielleicht später noch einen Kommentar abgeben.
Einen meiner virtuellen Server, den man durchaus als “produktiv” bezeichnen könnte, betreibe ich bereits unter der Development-Version der neuen Fassung von Ubuntu, namentlich Ubuntu 15.04 (Vivid Vervet). Wobei “produktiv” vielleicht übertrieben sein mag, Gitlab stellt den wichtigsten Dienst dar, alles andere dient mehr oder minder zu Testzwecken. Und von den Daten-Verzeichnissen existieren sogar regelmäßige Backups. Manche würden dies dennoch als Kamikaze bezeichnen, aber ich hatte einen einzigen Grund – und zwar lief die vorherige Version 14.10 nur wenig zufriedenstellend. Aus welchen Gründen auch immer, aber das Verzeichnis /run/systemd/sessions lief dermaßen voll, dass die maximale Kapazität jedes Mal binnen weniger Tage erreicht war und einen Neustart nötig werden ließ, da einige Dienste nicht mehr normal funktionierten. Es fanden sich zwar entsprechende Berichte anderer User, aber keine endgültige Lösung, also habe ich das Upgrade auf die Development-Fassung von 15.04 gewagt – und es bisher nicht bereut.
Turnusmäßig erledige ich Updates nahezu nebenbei, so wollte ich es auch diesmal handhaben. Doch nach dem Reboot war leider Redis nicht mehr aktiv. Redis ist auf der Maschine als PPA von Rowan Wookey installiert. Auch dies ist nachvollziehbar zu begründen, denn obwohl neuere Ubuntu-Versionen auch neuere Fassungen von Redis-Server mitbringen, so bietet das PPA auch für ältere Distributionen die jeweils neueste Version von Redis-Server. Zwar fehlt bislang eine Fassung für Ubuntu 15.04, aber diejenige für 14.10 (Utopic) funktionierte bislang problemlos.
Nur leider diesmal nicht. Wie sich herausstellte, war Redis bzw. waren die Binaries selbst nicht das Problem. Manuell ließ sich Redis normal starten, also musste es mit dem Startprozess nach dem Booten zusammen hängen. Ich erinnerte mich an einen Beitrag vor wenigen Tagen auf Heise, dass Ubuntu Vivid in Kürze vom Init-Prozess Upstart auf Systemd wechseln würde. Das war doch ein guter Anhaltspunkt…
Und gleichzeitig des Rätsels Lösung. Für Redis existierte nur eine Upstart-Datei /etc/init/redis-server.conf, sonst nichts. Weder ein klassisches Start-Stop-Skript in /etc/init.d/, noch sonstiges. Aber wie funktionierte nun Systemd genau, und wollte ich es überhaupt wissen? Wohl oder übel fanden sich Hinweise in zwei Heise-Artikel über das Init-System Teil 1 und Teil 2, sowie bei Ubuntu selbst.
Um Redis vor allem schnell wieder zum Laufen zu bringen, kopierte ich die Datei /lib/systemd/system/php5-fpm.service nach /lib/systemd/system/redis-server.service. Damit war ein einfaches Beispiel vorhanden, was nun an Redis angepasst werden musste. Das Ergebnis sieht wie folgt aus:
Doch das reichte noch nicht. Die bloße Existenz der Datei lässt den Service, hier Redis noch lange nicht starten:
$ sudo systemctl --type=service -a ● redis-server.service not-found inactive dead redis-server.service $ sudo systemctl list-unit-files redis-server.service disabled
Schade. Denn der neue Service musste dem System erst bekannt gemacht werden:
Ob die erstellte Systemd-Service-Datei in Ordnung ist, lässt sich übrigens wie folgt überprüfen:
$ sudo systemd-analyze verify /lib/systemd/system/redis-server.service
Anfangs wurden da einige Fehler benannt, denn ich hatte mehr oder minder die Kommandos aus der Upstart-Datei entnommen und in die entsprechenden Bereiche der Systemd-Datei gepackt. Beispielsweise müssen bei Systemd jedoch die absoluten Pfade angegeben werden… Als das erledigt war und die Anzahl der Fehlermeldungen bei der Prüfung stark zurück gegangen war, wagte ich folgenden Versuch, um den Dienst zu aktivieren:
$ sudo systemctl enable redis-server Created symlink from /etc/systemd/system/multi-user.target.wants/redis-server.service to /lib/systemd/system/redis-server.service.
Das sah doch recht erfolgversprechend aus! Denn:
$ sudo systemctl list-unit-files | grep redis redis-server.service enabled
Daher erfolgte der erste Versuch, Redis zu starten mittels
$ sudo service redis-server start
Dieser Versuch scheiterte jedoch aufgrund eines Fehlers in der Systemd-Service-Datei (man tastet sich ja so langsam heran). Als dieser behoben war, wollte Systemd nichts davon wissen, gab jedoch den Hinweis, dass man doch bitte das Kommando “systemctl daemon-reload” ausführen sollte, nachdem die Datei “redis-server.service” sich auf der Platte geändert hatte. Fand ich durchaus nett, ergo:
$ sudo systemctl daemon-reload
Und siehe da, nach dem erneuten Startversuch konnte Redis endlich wieder gestartet werden. Der Check sah soweit ebenfalls gut aus:
geschke@rostock:/lib/systemd/system$ ps ax | grep redis
422 ? Ssl 0:00 /usr/bin/redis-server 127.0.0.1:6379
429 pts/0 S+ 0:00 grep --color=auto redis
geschke@rostock:/lib/systemd/system$ sudo systemctl status redis-server.service
● redis-server.service - Redis Datastore Server
Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Active: active (running) since Do 2015-03-12 20:48:14 CET; 12s ago
Process: 421 ExecStart=/sbin/start-stop-daemon --start --chuid redis:redis --pidfile /var/run/redis/redis.pid --umask 007 --exec /usr/bin/redis-server -- /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
Process: 418 ExecStartPre=/bin/chown redis:redis /var/run/redis (code=exited, status=0/SUCCESS)
Process: 414 ExecStartPre=/bin/mkdir -p /var/run/redis (code=exited, status=0/SUCCESS)
Main PID: 422 (redis-server)
CGroup: /system.slice/redis-server.service
└─422 /usr/bin/redis-server 127.0.0.1:6379
Und Redis ließ sich wieder wie gewohnt ansprechen – womit auch Gitlab wieder lief. Jetzt fehlt zwar noch MongoDB, aber dessen Upstart-Skript ist bereits um einiges komplexer, so dass ich hier vielleicht einfach noch ein wenig warte, weitere Experimente auf andere Server verlege, oder mich gleich eines Docker-Containers bediene. Denn so viel Systemadministration, oder auch “DevOps” wollte ich heute gar nicht erleben… Aber vielleicht hilft dieser Beitrag dem einen oder anderen bei ähnlichen Problemen, in diesem Fall freue ich mich natürlich sehr!
