Systemd - Services Konfigurieren / verwalten

Nach dem Bootvorgang, in dem der Kernel das root-Filesystem eingebunden und alle notwendigen Module geladen hat, übernimmt der systemd-Daemon den weiteren Ablauf. Der klassische init-Prozess folgt dem in System V Verfahren und wird nach diesem auch SysVinit genannt. Er ist verantwortlich für das Starten der Dienste in der richtigen Reihenfolge, das Folgen und auch den Wechsel von Runleveln sowie für das Stoppen von Prozessen. Dieses Verfahren ist sehr robust, aber leider auch sehr statisch.

Systemd ist der Nachfolger, den mittlerweile alle Distributionen verwenden. Mit systemd gibt es einen Übergang vom statischen Starten von Skripten zum eventbasierten Starten. So können Bedingungen definiert werden, die erfüllt sein müssen, um Dienste starten zu können (beispielsweise wird der Webserver erst dann gestartet, wenn das Netzwerk verfügbar ist, oder ein Virenscanner, wenn ein USB-Stick eingesteckt wird).Der Start von Diensten mit systemd ist im Unterschied zu SysVinit hoch parallelisierbar. Als besonderes Feature ist systemd auch in der Lage, abgestürzte Dienste neu zu starten.

Systemd schickt sich an, den kompletten altbekannten und bewährten Bootvorgang auf den Kopf zu stellen. Den einen gehen die Änderungen zu weit, die anderen feiern mit systemd die Ankunft im neuen Jahrtausend. Tatsache ist, dass mit systemd Start-Skripte – genauer Startkonfigurationen – parallel ausgeführt werden können und nicht wie früher linear. Dazu kommt, dass systemd Programme voneinander kapselt und in eigenen Control Groups und Namespaces startet und so sicherstellt, dass bei Beenden eines Dienstes auch alle Prozesse im gleichen Namespace mit beendet werden und es keine verwaisten Prozesse mehr gibt.

Weitergehende Änderungen sind, dass mit journald ein eigenes Logging-Framework mitgeliefert wird, das es erlaubt, fälschungssichere Logs zu führen und so das altbekannte syslog ablösen will. timers in systemd sind in der Lage, klassische Cron-und Anacronjobs abzulösen, systemd-mounts könnten die fstab überflüssig machen.

Systemd wird mit Units verwaltet, Units kapseln verschiedene Aspekte eines Systems und können untereinander in Beziehung gesetzt werden. Die Definitionen der Units sind 78 einfache Textdateien, die ein wenig an ini-Dateien aus Windows erinnern. Die einzelnen UnitTypen sind die folgenden:

Begriffe:

Service Units werden benutzt, um Dienste und Prozesse zu starten.
Socket Units kapseln IPC oder Netzwerk-Sockets, die vor allem gebraucht werden, um Socket-basierend Dienste zu aktivieren.
Target Units können zur Gruppierung von Diensten oder zur Erstellung von Synchronisationspunkten benutzt werden (hiermit lassen sich Runlevel wie im SysVinit emulieren).
Device Units sind die Verbindung zu Kernel-Devices und können ebenfalls benutzt werden, um Device-basierende Dienste zu steuern.
Mount Units kontrollieren Mountpunkte im System.
Automount Units werden für zugriffs basiertes Einbinden von Dateisystemen benutzt und dienen insbesondere auch der Parallelisierung im Bootprozess.
Snapshot Units können den Status einer Anzahl von systemd-Units aufzeichnen und diesen Status durch Aktivierung auch wiederherstellen.
Timer Units bieten die Möglichkeit, zeitbasierte Steuerung anderer Units vorzunehmen.
Swap Units verwalten – analog zu Mount Units – Swap-Speicherplatz.
Path Units werden benutzt, um andere Dienste bei Veränderung von Dateisystemobjekten zuaktivieren.
Slice Units gruppieren Units in hierarchischer Form, die Systemprozesse – beispielsweise Service oder Scope Units – verwalten.
Scope Units gleichen Service Units, verwalten aber Fremdprozesse, statt sie nur zu starten.

Pfade:

/etc/systemd/system/: Hier können eigene systemd-services erstellt werden.
/usr/lib/systemd/system/: Hier werden wie systemd-services der Linux Packages abgelegt. (ACHTUNG: werden hier eigene Unite-Files erstellt, können diese überschrieben werden.)

# vim /etc/systemd/system/teamspeak.service

[Unit]
Description=TeamSpeak Server Service
After=network.target

[Service]
Type=forking
WorkingDirectory=/opt/teamspeak/
ExecStart=/opt/teamspeak/ts3server_startscript.sh start inifile=ts3server.ini
ExecStop=/opt/teamspeak/ts3server_startscript.sh stop
User=teamspeak
Group=teamspeak
PIDFile=/opt/teamspeak/ts3server.pid
Restart=always
RestartSec=9
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=teamspeak

[Install]
WantedBy=multi-user.target

Reloaden der Systemd Dienste und aktivieren / starten des TeamSeak-Services:

# systemctl daemon-reload

# systemctl start teamspeak.service
# systemctl enable teamspeak.service

Siehe dazu hier: → Manage Systemd Services

Oder klicke den Button um die Wikipage als Modalpopup zu öffnen. Manage Systemd

Mit dem Systemd wurde auch der Journald eingeführt. Er ist das zentrale Logging-Werkzeug von Systemd.

Siehe dazu hier: → RedHat journald

Oder klicke den Button um die Wikipage als Modalpopup zu öffnen. RedHat journald

Systemd - Services Konfigurieren / verwalten

Was ist Systemd?

Komponenten und Pfade von Systemd

Einrichten eines eigenen Systemd Services

Beispiel 1 - Einrichten von neuem Systemd TeamSpeak Service

Manage Systemd Services

Logs mit »journald«