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…
6 Comments
Kleiner Tipp: systemd kennt verschiedene Typen von Units, Dienste und Targets sind nur zwei davon. Dienste sind allerdings der Standardtyp, deswegen kann man in den meisten Befehlen
.service
weglassen.systemctl restart sshd
tut es also auch.hier ist auch ein chkconfig -l aufgeführt.
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
Hi Markus,
Danke für die Rückmeldung, ich hatte es eigentlich mit chkconfig –list (was ja die gleiche Option ist) versucht, allerdings wurden hierbei nicht alle Dienste angezeigt sondern maximal 10 Stück.
Ich habe gerade keine SLES12 zum testen zur Verfügung, werde es nächste Woche aber nochmal ausprobieren.
Gruß
Thorsten
Hi Markus,
ich habe auf einer aktuellen SLES12 Installation chkconfig -l ausgeführt. Hier bekomme ich nur von wenigen Diensten eine Rückmeldung. Es sind gerade mal 34 Zeilen inklusive den xinetd Diensten.
Die Auflistung von chkconfig enthält nicht mehr alle zu konfigurierten Dienste.
Gruß
Thorsten
Hi Thorsten,
ich meinte auch wie unter dem angegeben link zu sehen ein:
systemctl list-unit-files –type=service
Danke dir! Wer lesen kann ist natürlich im Vorteil 🙂