In dieser Woche war ich in München auf de w-jax. Erste Eindrücke habe ich ja in einem Blog Post kurz zusammengefasst. Als ich an einer Diskussion über die in der Software Entwicklung genutzten Werkzeuge teilnahm, ist auch der Sonatype Nexus ein Thema gewesen, dessen Installation ich ja schon einmal kurz zusammenfasst habe. Dabei ist mir aufgefallen, dass es nun eine neue Version des Nexus gibt und ich nun ein Update druchführen kann. Die Release Notes listen ja immerhin ein paar Änderungen auf, die man gerne ausprobieren würde.
Zu meiner Überraschung hat das per Fernwartung durchgeführte Update nicht funktioniert. Der Nexus beendete sich nicht wie gewünscht und irgendwie war die Fehlersiuation unklar. Daher habe ich diesen Versuch dann abgebrochen und alle weiteren Versuche auf einen späteren Termin verschoben.
Dieser ist nun gekommen.
Eine Fehleranalyse hat dann auch schnell die Ursache für das unklare Fehlverhalten ergeben. Das nexus.command aus meiner Installationsanleitung ist durch den launchctl gestartet und dann auf Anfrage auch beendet worden. Der Wrapper mit der Java-VM jedoch lief einfach weiter. Das hätte jedoch nicht passieren dürfen. Im Grunde wurde - nach vorbereitenden Schritten - der Nexus ja wie folgt gestartet:
# Nexus benötig einige offene Files...
if [ `ulimit -n` -lt 1024 ]; then
ulimit -n 1024
fi
exec $WRAPPER $WRAPPER_CONF wrapper.syslog.ident=nexus wrapper.pidfile=$PIDFILE wrapper.daemonize=false
In meiner Version habe ich jedoch das exec für einige Tests entfernt und dann nicht wieder eingefügt. Damit hat launchctl den Shell-Prozess und nicht, wie gewünscht, den Wrapper und die Java-VM kontrolliert. Beim Anhalten des Dienstes wurde daher auch die Shell zwar angehalten, der Nexus fühlte sich dadurch aber nicht weiter gestört.
Aus genau diesem Grund hatte ich das exec in das Shell-Skript eingefügt. Nachdem das Shell-Skript seine Schuldigkeit getan hatte, sollte durch den exec Systemaufruf der Prozess mit der Ausführung von Wrapper und Java-VM fortsetzen. Damit hätte launchctl auch den gewünschten Serverprozess kontrollieren und überwachen können. Beim Stoppen des Dienstes werden dann erst freundliche Ermahnungen an den Prozess gesendet, die mit der Zeit sehr, sehr nachhaltig werden.
Ich habe durch diesen dummen Fehler kaum etwas dabei gelernt, ausser dass man sehr genau auf seine ad hoc Anpassungen achten muss. Doch immerhin ist damit aber hier noch ein Blog Eintrag entstanden, der auf die Bedeutung dieses unscheinbaren Schlüsselworts exec hinweist.
Ist dieses Schlüsselwort erst einmal korrekt wieder eingesetzt (und wird dann sowohl das nexus.command wie auch der wrapper mit einem unfreundlichen kill -9 einmal aus dem System entfernt), kann die Installation des Updates wie geplant mit einigen wenigen Befehlen durchgeführt werden:
merlin:Users root$ cd /Volumes/Server/_nexus
merlin:_nexus root$ curl http://www.sonatype.org/downloads/nexus-2.2-01-bundle.tar.gz | tar xvzf -
merlin:_nexus root$ launchctl stop org.sonatype.nexus
merlin:_nexus root$ rm nexus
merlin:_nexus root$ ln -s nexus-2.2-01 nexus
merlin:_nexus root$ chown -R _nexus:_nexus nexus nexus-2.2-01
merlin:_nexus root$ launchctl start org.sonatype.nexus
Die alten Versionen des Nexus kann man erst einmal innerhalb des Verzeichnisses weiter aufbewahren. So spart man sich gegebenenfalls den Download, wenn doch irgendwann einmal vielleicht eine der älteren Versionen noch einmal reaktiviert werden muss.