SLES12: systemd ersetzt init

Da seit ca. Anfang Oktober 2015 SLES 12 für produktive SAP Umgebungen freigegeben ist, wurde es höchste Zeit mir mal systemd und dessen Benutzung etwas genauer anzuschauen.

In der Nutzung der daemons bzw. bei der Abarbeitung der früheren Runlevel hat sich hier einiges geändert.

SuSE hat hierzu auch ein Whitepaper für die Nutzung von systemd in SLES 12 heraus gegeben welches auch viele der Neuerungen aufführt. Das Whitepaper ist aktuell unter diesem Link verfügbar.

Ein paar Befehle welche ich ausprobiert habe schreibe ich mir hier herunter. Das ist aber keine vollständige Auflistung!

Runlevel:

Was früher einmal die Runlevel waren wird nun „target“ genannt. Diese werden nun folgendermaßen unterschieden:

Runlevel --------------- Target

0        --------------- poweroff.target

1        --------------- rescue.target

2,3,4    --------------- multi-user.target

5        --------------- graphical.target

6        --------------- reboot.target

Diese Targets wechselt man nun mit dem „systemctl“ Befehl im laufenden Betrieb. Beispiel:

# systemctl isolate reboot.target

Führt zu einem reboot des Linux systems. In meinen aktuellen Tests funktionierte allerdings auch noch „init 6“ welches ein Softlink darstellt auf den systemctl Befehl und das System zum reboot überführt. Auch die anderen „init #“ Befehle waren über Softlinks verfügbar.

Zusätzlich gibt es noch „systemctl reboot“ welches ohne die Targetinformation etc. ebenfalls zu einem reboot des Systems führt.

Setzen des default Target (früher Runlevel) funktioniert mit:

# systemctl set-default multi-user.target

Daemons:

Die Verwaltung der Dienste (daemons) macht mir allerdings noch etwas Kopfzerbrechen. Das meiste funktioniert erstmal mit dem systemctl Befehl.

Dienste für beim booten aktivieren/deaktivieren:

# systemctl enable sshd.service

# systemctl disable sshd.service

Aktuelles starten oder stoppen von Diensten:

# systemctl start sshd.service

# systemctl stop sshd.service

# systemctl restart sshd.service

Dabei bekommt man anschließend allerdings keine Rückmeldung über den gestarteten/gestoppten Dienst mehr. Man benötigt ein erneutes „systemctl status sshd.service“ und bekommt dann eine recht Umfangreiche Statusinformation. Das wiederum ist wirklich gut.

Die Statusinfo zeigt das Executable welches genutzt wurde, des Status des Dienstes und seit wann dieser gestartet wurde, Kindprozesse welche vom Dienst verwaltet werden, die PID und vieles mehr.

Eine übersichtliche Information welche Dienste denn zur Verfügung stehen und in welchem Status sich diese befinden hat mir allerdings bisher noch gefehlt. Also eine Auflistung der Dienste ähnlich dem früheren „chkconfig –list“ oder ähnliches.

Weiteres wird folgen…

Schlagwörter: HowTo, Linux Rescue HowTo, Test