Version: GSB 7Start/Stop/Status der GSB-Komponenten

Der vorliegende Abschnitt ist Teil einer kleinen Sammlung von kurzen Anleitungen und Ansatzpunkten für die Arbeiten eines GSB 7.5 Administrators. Erfahrungen mit vorherigen GSB 7 Installationen werden vorausgesetzt. Diese Dokumente sollen den Betriebsverantwortlichen den Umstieg erleichtern.

Contents 1 Hintergrundwissen 2 Dienste als systemd-Service 3 Direkte Nutzung von systemctl 3.1 Sonderfälle mit root-Berechtigungen 4 Das "gsb"-Hilfsskript

1 Hintergrundwissen

Im GSB 7.5 ist eine konsequente Umstellung auf systemd vollzogen worden.

2 Dienste als systemd-Service

Alle Dienste werden als systemd-Service gestartet. Die GSB Dienste werden hier nicht von der systemd-System Instanz kontrolliert sondern von einer im User-Kontext des cmadmin Users gestarteten Systemd-Instanz. Damit die User-Instanz beim Boot des Systems gestartet wird, muss der Befehl

loginctl enable-linger cmadmin

einmalig mit Root-Rechten ausgeführt werden. Ausnahme bleibt der Apache2, der aufgrund der Nutzung der privilegierten Ports 80 und 443 weiter mit Root-Rechten ausgeführt werden muss und deshalb durch die systemd-System Instanz gestartet wird.

Die systemd-Services nutzen systemd-Template Units. Das bedeutet, der Name der Servicedatei ist vom Format application@.service .

Aus einer Template-Unit können dann mehrere Instanzen gestartet werden, indem der Instanzname hinter dem @ angegeben wird: application@instanz1.service oder application@instanz2.service . Der GSB nutzt dieses Mechanismus um eine GSB-Komponente mit mehreren Konfigurationen starten zu können. Z.B. start der Service content-server@content-server-preview.service die Komponente /opt/gsb/active/content-server mit der Konfigurationsdatei /opt/gsb/runtime/content-server-preview.properties und den Umgebungsvariablen aus /opt/gsb/runtime/content-server-preview.env.

Die Dateien /opt/gsb/runtime/application.properties , /opt/gsb/runtime/application.env und /opt/gsb/runtime/content-server. properties werden auch geladen. Hierbei hat bei mehrfacher Definition eines Properties die content-server-preview.properties Priorität über die content-server.properties , die wiederum Priorität über die application.properties hat.

Ausnahme vom Template-Schema ist wiederum der Apache2.service, der als normaler Service ohne Instanziierung gestartet wird.

Alle Spring-Boot Applikationen des GSB, d.h. alle Komponenten außer Apache2 und Solr, öffnen einen Management-Port, auf dem sogenannte Actuator ausgeliefert werden. Die GSB-Systemd-Dateien nutzen den /actuator/health, um beim Start des Services eine Abfrage des Status durchzuführen. Der Service wird durch Systemd erst als gestartet (active) markiert, wenn der Actuator den Status UP zurückgibt. So wird das Abbilden von Abhängigkeiten zwischen auf einem System laufenden Services möglich. Der GSB-Installationsprozess erzeugt die Konfiguration der Abhängigkeiten, so dass die Dienste in der richtigen Reihenfolge gestartet und gestoppt werden.

Die Abbildung von Systemübergreifenden Abhängigkeiten ist nicht vorgesehen und muss durch andere Maßnahmen (z.B. vorgegebene Startreihenfolge der Systeme) vorgenommen werden.

3 Direkte Nutzung von systemctl

Die systemd-Unit Datein werden im Ordner /home/cmadmin/.config/systemd/user abgelegt. Um die systemd-User Instanz per systemctl anzusteuern, müssen die beiden Umgebungsvariablen

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

im Profil des Nutzers cmadmin gesetzt werden, wenn der Login nicht direkt als Nutzer cmadmin erfolgt sondern per su - cmadmin.

Die Kontrolle der Dienste im Nutzer-Kontext kann mittels systemctl --user erfolgen. Z.B.:

systemctl --user status content-server@content-server-preview
systemctl --user start cae@cae-preview
systemctl --user stop solr@solr-master
systemctl --user restart eventdispatcher@eventdispatcher

3.1 Sonderfälle mit root-Berechtigungen

Dienste die auf well-known-Ports lauschen müssen mit privilegierten Benutzern gestartet werden. Dies betrifft in der Regel den Apache-Webserver und ggf. einen LDAP-Dienst der Plattform.

4 Das "gsb"-Hilfsskript

Zur Vereinfachung der Kontrolle der GSB-Komponenten liefert der GSB ein Hilfsscript /opt/gsb/active/infrastructure/systemd/gsb mit. Dieses sollte für den einfacheren Aufruf bei der Installation nach /home/cmadmin/bin/gsb verlinkt werden. Das Script ermöglicht über die Kommands gsb start , gsb stop und gsb restart die Kontrolle der Dienste. gsb restart bildet einen sicheren Neustart ab. Durch die tief ins Betriebssystem verknüpfte Überwachungsfuntionalität von Systemd ist technisch sichergestellt, dass alle Prozesse des alten Services gestoppt sind, bevor der neue Service gestartet wird. Beim Aufruf der Kommandos ohne weitere Parameter werden alle GSB Dienste kontrolliert. Zur Kontrolle einzelner Dienste können diese als Parameter übergeben werden. Z.B.

gsb start content-server@content-server-preview cae@cae-preview

würde den content-server-preview und die cae-preview und alle weiteren konfigurierten Abhängigkeiten dieser Dienste starten. Das Suffix .service ist optional.

Außerdem gibt das gsb Script mit gsb status einen Status aller konfigurierten GSB-Dienste aus. Gestoppte oder fehlgeschlagene Dienste werden rot markiert, laufende Dienste werden grün markiert und startende oder stoppende Dienste werden gelb markiert.

Zu Beachten ist, dass auch nach einem gsb start Dienste, deren Abhängigkeiten noch nicht erfüllt sind, noch als gestoppt und damit rot angezeigt werden. Der Start-Job ist aber in systemd vorgemerkt, und wird ausgeführt sobald die Abhängigkeiten erfüllt sind. Zur Verdeutlichung gibt das gsb status Kommando am Ende der Ausgabe eine Liste der noch nicht vollständigen Systemd-Jobs aus.