19 Der Daemon systemd
#
systemd
ist für die Initialisierung des Systems verantwortlich und trägt die Prozess-ID 1. systemd
wird direkt vom Kernel gestartet und widersteht dem Signal 9, das in der Regel Prozesse beendet. Alle anderen Programme werden entweder direkt von systemd
oder von einem seiner untergeordneten Prozesse gestartet. systemd
ersetzt den System-V-init-Daemon und ist (durch die Unterstützung von init-Skripten) uneingeschränkt mit System-V-init kompatibel.
Der wichtigste Vorteil von systemd
ist der erheblich schnellere Systemstart durch die Parallelisierung der Dienststarts. Darüber hinaus startet systemd
einen Dienst nur dann, wenn er tatsächlich benötigt wird. Deamons werden nicht in jedem Fall beim Booten gestartet, sondern erst dann, wenn sie erstmalig benötigt werden. systemd
unterstützt außerdem Kernel-Steuergruppen (cgroups), das Erstellen von Snapshots und das Wiederherstellen des Systemstatus. Weitere Einzelheiten finden Sie unter http://www.freedesktop.org/wiki/Software/systemd/.
19.1 Das Konzept von systemd
#
Im folgenden Abschnitt wird das Konzept hinter systemd
erläutert.
systemd
ist ein System- und Sitzungsmanager für Linux und ist mit System V- und LSB-init-Skripts kompatibel. Die wichtigsten Funktionen von systemd
:
Parallelisierungsfunktionen
Socket- und D-Bus-Aktivierung zum Starten von Diensten
Starten der Daemons bei Bedarf
Verfolgen von Prozessen mithilfe von Linux-cgroups
Erstellen von Snapshots und Wiederherstellen des Systemstatus
Einhängepunkte und Automount-Punkte
Ausgereifte Dienststeuerlogik auf der Basis der Transaktionsabhängigkeiten
19.1.1 Unit-Datei #
Eine Unit-Konfigurationsdatei enthält Informationen zu einem Dienst, Socket, Gerät, Einhängepunkt, Automount-Punkt, einer Auslagerungsdatei oder Partition, einem Startziel, einem überwachten Dateisystempfad, einem von systemd
gesteuerten und überwachten Zeitgeber, einem Snapshot eines temporären Systemstatus, einem Ressourcenverwaltungs-Slice oder einer Gruppe extern erstellter Prozesse.
„Unit-Datei“systemd
ist in ein generischer Term für Folgendes:
Dienst. Informationen zu einem Prozess (z. B. Ausführung eines Daemon); Datei endet auf .service
Zielgruppen. Fassen Units zu Gruppen zusammen bzw. fungieren als Synchronisierungspunkte beim Starten; Datei endet auf .target
Sockets. Informationen zu einem IPC- oder Netzwerk-Socket oder einem Dateisystem-FIFO, für die socketbasierte Aktivierung (wie
inetd
); Datei endet auf .socketPath. Dient als Auslöser von anderen Units (z. B. Ausführen eines Dienstes, wenn Dateien geändert werden); Datei endet auf .path
Zeitgeber. Informationen zu einem gesteuerten Zeitgeber für die zeitgeberbasierte Aktivierung; Datei endet auf .timer
Einhängepunkt. In der Regel automatisch durch den fstab-Generator erzeugt; Datei endet auf .mount
Automount-Punkt. Informationen zu einem Dateisystem-Automount-Punkt; Datei endet auf .automount
Swap. Informationen zu einem Auslagerungsgerät oder einer Auslagerungsdatei für das Arbeitsspeicher-Paging; Datei endet auf .swap
Gerät. Informationen zu einer Geräte-Unit in der Geräte-Baumstruktur sysfs/udev(7); Datei endet auf .device
Bereich/Slice. Konzept für die hierarchische Verwaltung von Ressourcen einer Prozessgruppe; Datei endet auf .scope/.slice
Weitere Informationen zu systemd
-Unit-Dateien finden Sie in http://www.freedesktop.org/software/systemd/man/systemd.unit.html
19.2 Grundlegende Verwendung #
Im System V-init-System werden Dienste mit mehreren Kommandos verarbeitet – mit init-Skripten, insserv
, telinit
und anderen. systemd
erleichtert die Dienstverwaltung, da ein einziges Kommando die meisten Dienstverarbeitungsaufgaben abdeckt: systemctl
. Hierbei gilt die Syntax „Kommando plus Subkommando“ wie bei git
oder zypper
:
systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS
Vollständige Anweisungen finden Sie in man 1 systemctl
.
Wenn die Ausgabe an ein Terminal geht (und nicht an eine Pipe oder Datei usw.), senden die systemd
-Kommandos standardmäßig eine ausführliche Ausgabe an einen Pager. Mit der Option --no-pager
deaktivieren Sie den Paging-Modus.
systemd
unterstützt außerdem die Bash-Vervollständigung. Hierbei geben Sie die ersten Buchstaben eines Subkommandos ein und drücken dann →|. Diese Funktion ist nur in der bash
-Shell verfügbar und das Paket bash-completion
muss installiert sein.
19.2.1 Verwalten von Diensten auf einem laufenden System #
Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (start
, stop
usw.). Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:
systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
- System V-init
rcMY_SERVICE(S) reload|restart|start|status|stop|...
Mit systemd
können Sie mehrere Dienste gleichzeitig verwalten. Im Gegensatz zu System V-init, bei dem die init-Skripts einzeln nacheinander ausgeführt werden, führen Sie ein einziges Kommando aus, beispielsweise:
>
sudo
systemctl start MY_1ST_SERVICE MY_2ND_SERVICE
So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab:
>
sudo
systemctl list-unit-files --type=service
Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd
und System V-init:
Aufgabe |
|
System V-init-Kommando |
---|---|---|
Starten. |
start |
start |
Stoppen. |
stop |
stop |
Neu starten. Fährt Dienste herunter und startet sie dann neu. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet. |
restart |
restart |
Bedingt neu starten. Startet Dienste neu, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden. |
try-restart |
try-restart |
Neu laden.
Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen. Anwendungsbeispiel: Weisen Sie Apache an, eine bearbeitete Konfigurationsdatei |
reload |
reload |
Neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet. |
reload-or-restart |
n/a |
Bedingt neu laden oder neu starten. Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden. |
reload-or-try-restart |
n/a |
Ausführliche Statusinformationen abrufen.
Zeigt Informationen zum Dienststatus. Das Kommando |
status |
status |
Kurze Statusinformationen abrufen. Gibt an, ob Dienste aktiv sind oder nicht. |
is-active |
status |
19.2.2 Dienste dauerhaft aktivieren/deaktivieren #
Mit den Dienstverwaltungskommandos im vorangegangenen Abschnitt können Sie die Dienste für die aktuelle Sitzung bearbeiten. systemd
Mit können Sie Dienste außerdem dauerhaft aktivieren oder deaktivieren, so dass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Kommandozeile tun.
19.2.2.1 Aktivieren/Deaktivieren von Diensten über die Kommandozeile #
Die folgende Tabelle zeigt die wichtigsten Aktivierungs- und Deaktivierungskommandos für systemd
und System V-init:
Wenn ein Dienst über die Kommandozeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Soll ein Dienst nach dem Aktivieren sofort gestartet werden, führen Sie explizit systemctl start MEIN_DIENST
oder rc MEIN_DIENST start
aus.
Aufgabe |
|
System V-init-Kommando |
---|---|---|
Aktivieren von. |
|
|
Deaktivieren. |
|
|
Überprüfen. Zeigt an, ob ein Dienst aktiviert ist oder nicht. |
|
|
Erneut aktivieren. Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll. |
|
n/v |
Maskierung. Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst vollständig deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden. |
|
n/v |
Demaskieren. Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde. |
|
n/v |
19.3 Systemstart und Zielverwaltung #
Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von systemd
verwaltet. Von diesem Gesichtspunkt aus kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.
19.3.1 Ziele im Vergleich zu Runlevels #
Bei System V-init wurde das System in ein sogenanntes „Runlevel“ gebootet. Ein Runlevel definiert, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Die Runlevels sind numeriert. Die bekanntesten Runlevels sind 0
(System herunterfahren), 3
(Mehrbenutzermodus mit Netzwerk) und 5
(Mehrbenutzermodus mit Netzwerk und Anzeigemanager).
systemd
führt mit den sogenannten „Ziel-Units ein neues Konzept ein“. Dennoch bleibt die Kompatibilität mit dem Runlevel-Konzept uneingeschränkt erhalten. Die Ziel-Units tragen Namen statt Zahlen und erfüllen bestimmte Zwecke. Mit den Zielen local-fs.target
und swap.target
werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.
Das Ziel graphical.target
stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel 5. Komplexe Ziele wie graphical.target
fungieren als „Metaziele“, in denen eine Teilmenge anderer Ziele vereint ist. Mit systemd
können Sie problemlos vorhandene Ziele kombinieren und so benutzerdefinierte Ziele bilden. Damit bietet dieses Kommando eine hohe Flexibilität.
Die nachfolgende Liste zeigt die wichtigsten systemd
-Ziel-Units. Eine vollständige Liste finden Sie in man 7 systemd.special
.
systemd
-Ziel-Units #default.target
Das Ziel, das standardmäßig gebootet wird. Kein „reales“ Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie
graphic.target
. Kann über YaST dauerhaft geändert werden (siehe Abschnitt 19.4, „Verwalten von Diensten mit YaST“). Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parametersystemd.unit=MEIN_ZIEL.target
am Bootprompt ein.emergency.target
Startet eine Notfall-Shell über die Konsole. Dieses Kommando darf nur an der Boot-Eingabeaufforderung im Format
systemd.unit=emergency.target
verwendet werden.graphical.target
Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager.
halt.target
Fährt das System herunter.
mail-transfer-agent.target
Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind.
multi-user.target
Startet ein Mehrbenutzersystem mit Netzwerk.
reboot.target
Bootet das System neu.
rescue.target
Startet ein Einzelbenutzersystem ohne Netzwerk.
Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd
besondere Ziele mit der Bezeichnung runlevelX.target
, denen die entsprechenden, mit X nummerierten Runlevels zugeordnet sind.
Mit dem Kommando systemctl get-default
ermitteln Sie das aktuelle Ziel.
systemd
-Ziel-Units #
System V-Runlevel |
|
Beschreibung |
---|---|---|
0 |
|
System herunterfahren |
1, S |
|
Einzelbenutzermodus |
2 |
|
Lokaler Mehrbenutzermodus ohne entferntes Netzwerk |
3 |
|
Mehrbenutzer-Vollmodus mit Netzwerk |
4 |
|
Nicht verwendet/benutzerdefiniert |
5 |
|
Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager |
6 |
|
Systemneustart |
systemd
ignoriert /etc/inittab
Die Runlevels in einem System V-init-System werden in /etc/inittab
konfiguriert. Bei systemd
wird diese Konfiguration nicht verwendet. Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter Abschnitt 19.5.4, „Erstellen von benutzerdefinierten Zielen“.
19.3.1.1 Kommandos zum Ändern von Zielen #
Mit den folgenden Kommandos arbeiten Sie mit den Ziel-Units:
Aufgabe |
|
System V-init-Kommando |
---|---|---|
Aktuelles Ziel/Runlevel ändern |
|
|
Zum standardmäßigen Ziel/Runlevel wechseln |
|
n/v |
Aktuelles Ziel/Runlevel abrufen |
Bei |
oder
|
Standard-Runlevel dauerhaft ändern |
Verwenden Sie die Dienste-Verwaltung, oder führen Sie das folgende Kommando aus:
|
Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile
in |
Standard-Runlevel für den aktuellen Bootprozess ändern |
Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:
|
Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein. |
Abhängigkeiten für ein Ziel/Runlevel anzeigen |
„Requires“ (Benötigt) zeigt eine Liste der harten Abhängigkeiten (die in jedem Fall aufgelöst werden müssen), „Wants“ (Erwünscht) dagegen eine Liste der weichen Abhängigkeiten (die nach Möglichkeit aufgelöst werden). |
n/v |
19.3.2 Fehlersuche beim Systemstart #
systemd
bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Services mit dem jeweiligen Status prüfen (ohne durch /var/log/
blättern zu müssen). Mit systemd
können Sie zudem den Startvorgang scannen und so ermitteln, wie lang das Starten der einzelnen Dienste dauert.
19.3.2.1 Prüfen des Startvorgangs der Dienste #
Mit dem Kommando systemctl
erzeugen Sie eine Liste aller Dienste, die seit dem Booten des Systems gestartet wurden. Hier werden alle aktiven Dienste wie im nachstehenden (gekürzten) Beispiel aufgeführt. Mit systemctl status MEIN_DIENST
erhalten Sie weitere Informationen zu einem bestimmten Dienst.
#
systemctl
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
[...]
iscsi.service loaded active exited Login and scanning of iSC+
kmod-static-nodes.service loaded active exited Create list of required s+
libvirtd.service loaded active running Virtualization daemon
nscd.service loaded active running Name Service Cache Daemon
chronyd.service loaded active running NTP Server Daemon
polkit.service loaded active running Authorization Manager
postfix.service loaded active running Postfix Mail Transport Ag+
rc-local.service loaded active exited /etc/init.d/boot.local Co+
rsyslog.service loaded active running System Logging Service
[...]
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Soll die Ausgabe auf Dienste beschränkt werden, die nicht gestartet werden konnten, geben Sie die Option --failed
an:
#
systemctl --failed
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
apache2.service loaded failed failed apache
NetworkManager.service loaded failed failed Network Manager
plymouth-start.service loaded failed failed Show Plymouth Boot Screen
[...]
19.3.2.2 Fehlersuche für die Startzeit #
Mit dem Kommando systemd-analyze
in systemd
führen Sie die Fehlersuche für die Startzeit durch. Hiermit werden der Gesamtzeitaufwand für den Startvorgang sowie eine Liste der beim Starten angeforderten Dienste angezeigt. Auf Wunsch kann auch eine SVG-Grafik erstellt werden, aus der hervorgeht, wie lange der Start der Dienste im Vergleich zu den anderen Diensten dauerte.
- Auflisten der Startzeit des Systems
#
systemd-analyze Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms- Auflisten der Startzeit der Dienste
#
systemd-analyze blame 15.000s backup-rpmdb.service 14.879s mandb.service 7.646s backup-sysconfig.service 4.940s postfix.service 4.921s logrotate.service 4.640s libvirtd.service 4.519s display-manager.service 3.921s btrfsmaintenance-refresh.service 3.466s lvm2-monitor.service 2.774s plymouth-quit-wait.service 2.591s firewalld.service 2.137s initrd-switch-root.service 1.954s ModemManager.service 1.528s rsyslog.service 1.378s apparmor.service [...]- Grafische Darstellung der Startzeit der Dienste
#
systemd-analyze plot > jupiter.example.com-startup.svg
19.3.2.3 Prüfen des gesamten Startvorgangs #
Mit den obigen Kommandos werden die gestarteten Dienste und ihre Startzeiten aufgelistet. Eine detailliertere Übersicht erhalten Sie, wenn Sie folgende Parameter an der Boot-Eingabeaufforderung angeben, damit systemd
ein ausführliches Protokoll des gesamten Startvorgangs erstellt.
systemd.log_level=debug systemd.log_target=kmsg
systemd
schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer. Diesen Puffer zeigen Sie mit dmesg
an:
>
dmesg -T | less
19.3.3 System V-Kompatibilität #
systemd
ist mit System V kompatibel, sodass Sie vorhandene System V-init-Skripte weiterhin nutzen können. Es gibt allerdings mindestens ein bekanntes Problem, bei dem ein System V-init-Skript nicht ohne Weiteres mit systemd
zusammenarbeitet: Wenn Sie einen Dienst als ein anderer Benutzer über su
oder sudo
in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.
Wenn Sie den Benutzer mit su
oder sudo
ändern, wird eine PAM-Sitzung gestartet. Diese Sitzung wird beendet, sobald das init-Skript abgeschlossen ist. Als Folge wird auch der Service, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor:
Erstellen Sie einen Service-Datei-Wrapper mit demselben Namen wie das init-Skript und der Dateinamenerweiterung
.service
:[Unit] Description=DESCRIPTION After=network.target [Service] User=USER Type=forking1 PIDFile=PATH TO PID FILE1 ExecStart=PATH TO INIT SCRIPT start ExecStop=PATH TO INIT SCRIPT stop ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1 [Install] WantedBy=multi-user.target2
Ersetzen Sie alle Werte in GROSSBUCHSTABEN durch die entsprechenden Werte.
Starten Sie den Daemon mit
systemctl start ANWENDUNG
.
19.4 Verwalten von Diensten mit YaST #
Grundlegende Aufgaben können auch mit dem YaST-Modul Dienste-Verwaltung ausgeführt werden. Hiermit werden das Starten, Stoppen, Aktivieren und Deaktivieren von Diensten unterstützt. Darüber hinaus können Sie den Status eines Dienstes abrufen und das Standardziel ändern. Starten Sie das YaST-Modul mit
› › .- Ändern des
Zum Ändern des Ziels, in das das System gebootet wird, wählen Sie ein Ziel in der Dropdown-Liste
aus. Die häufigsten Ziele sind (Grafische Oberfläche; öffnet einen grafischen Anmeldebildschirm) und (Mehrbenutzer; startet das System im Kommandozeilenmodus).- Starten oder Stoppen eines Dienstes
Wählen Sie einen Dienst in der Tabelle aus. Die Spalte
zeigt, ob er derzeit ausgeführt wird ( ) oder nicht ( ). Mit bzw. schalten Sie den Status um.Durch das Starten und Stoppen eines Dienstes wird sein Status für die aktuelle Sitzung geändert. Soll der Status beim Neubooten geändert werden, müssen Sie den Dienst aktivieren oder deaktivieren.
- Definieren des Verhaltens beim Starten von Diensten
Dienste können entweder automatisch bei Booten oder manuell gestartet werden. Wählen Sie einen Dienst in der Tabelle aus. Die Spalte
zeigt, ob er derzeit gestartet ist oder . Mit schalten Sie den Status um.Um den Status eines Dienstes in der aktuellen Sitzung zu ändern, müssen Sie ihn wie oben beschrieben starten oder stoppen.
- Anzeigen von Statusmeldungen
Zum Anzeigen der Statusmeldungen für einen Dienst wählen Sie den gewünschten Dienst in der Liste aus und wählen Sie
. Die Ausgabe ist mit der Ausgabe des Befehlssystemctl
-l
status MEIN_DIENST identisch.
19.5 Anpassen systemd
#
In den folgenden Abschnitten finden Sie einige Beispiele, wie Sie systemd
individuell anpassen.
Wenn Sie systemd
anpassen, verwenden Sie stets das Verzeichnis /etc/systemd/
, nie das Verzeichnis /usr/lib/systemd/
. Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd
überschrieben.
19.5.1 Anpassen von Unit-Dateien #
Zum Anpassen von Unit-Dateien wird das Kommando systemctl edit DIENST
empfohlen. Dieses Kommando startet den Standardtexteditor und erstellt ein Verzeichnis mit der Datei override.conf
file unter /etc/systemd/system/NAME.service.d/
. Das Kommando benachrichtigt außerdem den laufenden systemd
-Vorgang über die Änderungen.
Alternativ können Sie mit dem Kommando systemctl edit --full DIENST
eine Kopie der Originaldatei zum Bearbeiten anstelle einer leeren Datei öffnen. Achten Sie beim Bearbeiten der Datei darauf, alle vorhandenen Abschnitte beizubehalten.
Ändern Sie als Übung den Zeitraum, den das System auf den Start von MariaDB warten soll. Führen Sie als root das Kommando systemctl edit --full mariadb.service
aus. Die geöffnete Datei ist in etwa wie folgt aufgebaut:
[Unit] Description=MySQL server Wants=basic.target Conflicts=mariadb.target After=basic.target network.target [Install] WantedBy=multi-user.target Alias=mysql.service [Service] Restart=on-abort Type=notify ExecStartPre=/usr/lib/mysql/mysql-systemd-helper install ExecStartPre=/usr/lib/mysql/mysql-systemd-helper upgrade ExecStart=/usr/lib/mysql/mysql-systemd-helper start # Configures the time to wait for start-up/stop TimeoutSec=300 # Prevent writes to /usr, /boot, and /etc ProtectSystem=full # Prevent accessing /home, /root and /run/user ProtectHome=true UMask=007
Passen Sie den Wert für TimeoutSec
an und speichern Sie die Änderungen. Zum Aktivieren der Änderungen führen Sie als root das Kommando systemctl daemon-reload
aus.
Weitere Informationen finden Sie auf den man-Seiten, die Sie mit dem Kommando man 1 systemctl
aufrufen können.
19.5.2 Erstellen von Drop-in-Dateien #
Bei kleineren Änderungen an einer Konfigurationsdatei verwenden Sie sogenannte Drop-in-Dateien. Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.
Um beispielsweise einen einzigen Wert für den Dienst foobar in /usr/lib/systemd/system/ foobar.service
zu ändern, gehen Sie wie folgt vor:
Erstellen Sie ein Verzeichnis mit dem Namen
/etc/systemd/system/FOOBAR.service.d/
.Beachten Sie das Suffix
.d
. Ansonsten muss der Name des Verzeichnisses mit dem Namen des Dienstes übereinstimmen, der mit der Drop-in-Datei gepatcht werden soll.Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen
your_modification.conf
.Diese Datei darf nur eine Zeile mit dem zu ändernden Wert enthalten.
Speichern Sie Ihre Änderungen in die Datei.
Um Namenskonflikte zwischen Ihren Drop-in-Dateien und den von SUSE bereitgestellten Dateien zu vermeiden, wird empfohlen, allen Drop-in-Dateinamen eine zweistellige Zahl und einen Bindestrich voranzustellen, beispielsweise 80-override.conf
.
Die folgenden Bereiche sind reserviert:
0-19
ist fürsystemd
-Upstream reserviert20-25
ist fürsystemd
reserviert (von SUSE bereitgestellt)26-29
ist für SUSE-Pakete reserviert (außer systemd)50
ist für Drop-in-Dateien reserviert, die mitsystemctl set-property
erstellt werden.
Geben Sie eine zweistellige Zahl oberhalb dieses Bereichs an, damit die von SUSE bereitgestellten Drop-in-Dateien Ihre eigenen Drop-in-Dateien nicht überschreiben.
Mit systemctl cat $UNIT
können Sie die Dateien auflisten und überprüfen, die in der Unit-Konfiguration berücksichtigt werden.
19.5.3 Konvertieren von xinetd
-Diensten in systemd
#
Seit der Version SUSE Linux Enterprise Server 15 wurde die xinetd
-Infrastruktur entfernt. In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte xinetd
-Dienstdateien in systemd
-Sockets konvertieren.
Für jede xinetd
-Dienstdatei benötigen Sie mindestens zwei systemd
-Unit-Dateien: die Socket-Datei (*.socket
) und eine zugehörige Dienstdatei (*.service
). Die Socket-Datei weist systemd
an, welcher Socket erstellt werden soll, und die Dienstdatei weist systemd
an, welche ausführbare Datei gestartet werden soll.
Betrachten Sie das folgende Beispiel für eine xinetd
-Dienstdatei:
#
cat /etc/xinetd.d/example
service example
{
socket_type = stream
protocol = tcp
port = 10085
wait = no
user = user
group = users
groups = yes
server = /usr/libexec/example/exampled
server_args = -auth=bsdtcp exampledump
disable = no
}
Zum Konvertieren in systemd
benötigen Sie die folgenden beiden Dateien:
#
cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false
[Install]
WantedBy=sockets.target
#
cat /usr/lib/systemd/system/example.service
[Unit]
Description=example
[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket
Eine vollständige Liste der Socket- und Dienstdateioptionen für systemd
finden Sie auf den man-Seiten zu systemd.socket und systemd.service (man 5 systemd.socket
, man 5 systemd.service
).
19.5.4 Erstellen von benutzerdefinierten Zielen #
Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können. Mit systemd
können Sie beliebig viele benutzerdefinierte Ziele erstellen. Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise graphical.target
.
Kopieren Sie die Konfigurationsdatei
/usr/lib/systemd/system/graphical.target
in/etc/systemd/system/MEIN_ZIEL.target
und passen Sie sie nach Bedarf an.Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen („harten“) Abhängigkeiten für das Ziel. Um auch die erwünschten („weichen“) Abhängigkeiten abzudecken, erstellen Sie ein Verzeichnis mit dem Namen
/etc/systemd/system/MEIN_ZIEL.target.wants
.Legen Sie für jeden erwünschten Dienst einen symbolischen Link von
/usr/lib/systemd/system
in/etc/systemd/system/MEIN_ZIEL.target.wants
an.Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die
systemd
-Konfiguration neu. Damit wird das neue Ziel verfügbar:>
sudo
systemctl daemon-reload
19.6 Erweiterte Nutzung #
In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren. Eine noch eingehendere Dokumentation zu systemd
finden Sie in der Serie von Lennart Pöttering zu systemd
für Administratoren unter http://0pointer.de/blog/projects.
19.6.1 Bereinigen von temporären Verzeichnissen #
systemd
unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse. Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. tmpfiles.d
(verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien /etc/tmpfiles.d/*.conf
, /run/tmpfiles.d/*.conf
und /usr/lib/tmpfiles.d/*.conf
aus. Die Konfiguration in /etc/tmpfiles.d/*.conf
hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In /usr/lib/tmpfiles.d/*.conf
speichern die Pakete die Konfigurationsdateien.)
Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann. Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben:
Type Path Mode UID GID Age Argument r /tmp/.X[0-9]*-lock
So rufen Sie den Status aus dem tmpfile-Zeitgeber ab:
>
sudo
systemctl status systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static) Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories. Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.
Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter man 5 tmpfiles.d
.
19.6.2 Systemprotokoll #
In Abschnitt 19.6.9, „Fehlersuche für Dienste“ wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen. Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt. Sie können auch auf das gesamte von systemd
geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen. Mit dem Befehl journalctl
zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen. Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter man 1 journalctl
.
19.6.3 Aufnahmen #
Mit dem Subkommando systemd
können Sie den aktuellen Status von isolate
als benannten Snapshot speichern und später wiederherstellen. Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können. Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht. Der Snapshot-Name muss auf .snapshot
enden.
- Erstellen eines Snapshots
>
sudo
systemctl snapshot MY_SNAPSHOT.snapshot- Löschen eines Snapshots
>
sudo
systemctl delete MY_SNAPSHOT.snapshot- Anzeigen eines Snapshots
>
sudo
systemctl show MY_SNAPSHOT.snapshot- Aktivieren eines Snapshots
>
sudo
systemctl isolate MY_SNAPSHOT.snapshot
19.6.4 Laden der Kernelmodule #
Mit systemd
können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in /etc/modules-load.d
. Die Datei sollte den Namen MODUL.conf haben und den folgenden Inhalt aufweisen:
# load module MODULE at boot time MODULE
Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter /usr/lib/modules-load.d
installiert. Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter /etc/modules-load.d
Vorrang.
Weitere Informationen finden Sie auf der man-Seite zu modules-load.d(5)
.
19.6.5 Ausführen von Aktionen vor dem Laden eines Dienstes #
Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in /etc/init.d/before.local
festgelegt werden. Dieses Verfahren wird in systemd
nicht mehr unterstützt. Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:
- Laden der Kernelmodule
Erstellen Sie eine Drop-in-Datei im Verzeichnis
/etc/modules-load.d
(Syntax sieheman modules-load.d
).- Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers
Erstellen Sie eine Drop-in-Datei in
/etc/tmpfiles.d
(Syntax sieheman tmpfiles.d
).- Weitere Aufgaben
Erstellen Sie eine Systemdienstdatei (beispielsweise
/etc/systemd/system/before.service
) anhand der folgenden Schablone:[Unit] Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE [Service] Type=oneshot RemainAfterExit=true ExecStart=YOUR_COMMAND # beware, executable is run directly, not through a shell, check the man pages # systemd.service and systemd.unit for full syntax [Install] # target in which to start the service WantedBy=multi-user.target #WantedBy=graphical.target
Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Kommandos aus (als
root
):>
sudo
systemctl daemon-reload>
sudo
systemctl enable beforeBei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen:
>
sudo
systemctl daemon-reload
19.6.6 Kernel-Steuergruppen (cgroups) #
Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde. Einige Dienste (z. B. Apache) erzeugen zahlreiche externe Prozesse (z. B. CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen. Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich. Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf. einige untergeordnete Dienste weiterhin aktiv.
Bei systemd
wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist. cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden. systemd
benennt die cgroups dabei nach dem jeweiligen Dienst. Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.
Mit dem Kommando systemd-cgls
erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:
#
systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│ ├─session-102.scope
│ │ ├─12426 gdm-session-worker [pam/gdm-password]
│ │ ├─15831 gdm-session-worker [pam/gdm-password]
│ │ ├─15839 gdm-session-worker [pam/gdm-password]
│ │ ├─15858 /usr/lib/gnome-terminal-server
[...]
└─system.slice
├─systemd-hostnamed.service
│ └─17616 /usr/lib/systemd/systemd-hostnamed
├─cron.service
│ └─1689 /usr/sbin/cron -n
├─postfix.service
│ ├─ 1676 /usr/lib/postfix/master -w
│ ├─ 1679 qmgr -l -t fifo -u
│ └─15590 pickup -l -t fifo -u
├─sshd.service
│ └─1436 /usr/sbin/sshd -D
[...]
Weitere Informationen zu cpgroups finden Sie im Chapter 10, Kernel control groups.
19.6.7 Beenden von Diensten (Senden von Signalen) #
Wie in Abschnitt 19.6.6, „Kernel-Steuergruppen (cgroups)“ erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden. Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste. Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.
Durch das Konzept von systemd
, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, sodass Sie ein Signal zu diesen Prozessen senden können. Mit Use systemctl kill
senden Sie die Signale an die Dienste. Eine Liste der verfügbaren Signale finden Sie in man 7 signals
.
- Senden von
SIGTERM
an einen Dienst SIGTERM
ist das standardmäßig gesendete Signal.>
sudo
systemctl kill MY_SERVICE- Senden von SIGNAL an einen Dienst
Mit der Option
-s
legen Sie das zu sendende Signal fest.>
sudo
systemctl kill -s SIGNAL MY_SERVICE- Auswählen von Prozessen
Standardmäßig sendet das Kommando
kill
das Signal analle
Prozesse der angegebenen cgroup. Sie können dies jedoch auf den Prozesscontrol
odermain
beschränken. Damit können Sie beispielsweise das Neuladen der Konfiguration eines Dienstes mit dem SignalSIGHUP
erzwingen:>
sudo
systemctl kill -s SIGHUP --kill-who=main MY_SERVICE
19.6.8 Wichtige Hinweise zum D-Bus-Dienst #
Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd
-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. dbus
ist zwar ein eigenständiger Dämon, bildet jedoch auch einen wesentlichen Bestandteil der init-Infrastruktur.
Das Beenden von dbus
oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten. Hiermit wird die systemd
-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd
-Funktionen unbrauchbar werden.
Das Beenden oder Neustarten von dbus
wird daher weder empfohlen noch unterstützt.
Nach einer Aktualisierung von dbus
oder dbus
-Paketen fällt ein Neustart an. Wenn Sie sich nicht sicher sind, ob ein Neustart erforderlich ist, führen Sie den Befehl sudo zypper ps -s
aus. Ist dbus
unter den aufgelisteten Diensten zu finden, müssen Sie das System neu starten.
Beachten Sie, dass dbus
selbst dann aktualisiert wird, wenn in der Konfiguration der automatischen Aktualisierungen festgelegt ist, dass die Pakete, die einen Neustart erfordern, übersprungen werden sollen.
19.6.9 Fehlersuche für Dienste #
Standardmäßig ist die Ausgabe von systemd
auf ein Minimum beschränkt. Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe. Bei einem Fehler wird eine kurze Fehlermeldung angezeigt. Mit systemctl status
können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.
systemd
umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden. Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen. Das Kommando status
hat eine ähnliche Funktion wie tail
und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.
- Anzeigen von Fehlern beim Starten von Diensten
Wenn ein Dienst nicht gestartet wird, erhalten Sie mit
systemctl status MEIN_DIENST
eine ausführliche Fehlermeldung:#
systemctl start apache2 Job failed. See system journal and 'systemctl status' for details.#
systemctl status apache2 Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled) Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/apache2.service Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line 205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>- Anzeigen der letzten n Dienstmeldungen
Standardmäßig zeigt das Subkommando
status
die letzten zehn Meldungen an, die ein Dienst ausgegeben hat. Mit dem Parameter--lines=n
legen Sie eine andere Anzahl fest:>
sudo
systemctl status chronyd>
sudo
systemctl --lines=20 status chronyd- Anzeigen von Dienstmeldungen im Anhängemodus
Mit der Option „--follow“ erhalten Sie einen
Live-Stream
mit Dienstmeldungen; diese Option entsprichttail
-f
:>
sudo
systemctl --follow status chronyd- Ausgabeformat der Meldungen
Mit dem Parameter
--output=mode
legen Sie das Ausgabeformat für die Dienstmeldungen fest. Die wichtigsten Modi sind:short
Das Standardformat. Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.
verbose
Vollständige Ausgabe mit sämtlichen Feldern.
cat
Kurze Ausgabe ohne Zeitstempel.
19.7 systemd
-Zeitgeber-Units #
Ähnlich wie Cron bieten systemd
-Zeitgeber-Units einen Mechanismus für die Planung von Aufträgen unter Linux. Die systemd
-Zeitgeber-Units dienen zwar demselben Zweck wie Cron, eröffnen allerdings mehrere Vorteile.
Aufträge, die mit einer Zeitgeber-Unit geplant werden, können von anderen
systemd
-Diensten abhängig sein.Zeitgeber-Units werden wie normale
systemd
-Dienste behandelt und können daher mitsystemctl
verwaltet werden.Die Zeitgeber können in Echtzeit und monoton sein.
Die Zeit-Units werden im
systemd
-Journal protokolliert, wodurch ihre Verwaltung und Fehlerbehebung vereinfacht werden.
systemd
-Zeitgeber-Units sind mit der Dateinamenerweiterung .timer
gekennzeichnet.
19.7.1 systemd
-Zeitgebertypen #
Zeitgeber-Units können monotone Zeitgeber und Echtzeit-Zeitgeber nutzen.
Ähnlich wie Cronjobs werden Echtzeit-Zeitgeber durch Kalenderereignisse ausgelöst. Echtzeit-Zeitgeber werden mit der Option
OnCalendar
definiert.Monotone Zeitgeber werden ausgelöst, sobald ein angegebener Zeitraum nach einem bestimmten Startpunkt vergangen ist. Dies ist beispielsweise ein Systemstart-Ereignis oder ein System-Unit-Aktivierungsereignis. Für die Definition von monotonen Zeitgebern stehen mehrere Optionen zur Auswahl, u. a.
OnBootSec
,OnUnitActiveSec
undOnTypeSec
. Monotone Zeitgeber sind nicht permanent und werden nach jedem Neustart zurückgesetzt.
19.7.2 systemd
-Zeitgeber und Dienst-Units #
Für jede Zeitgeber-Unit muss eine entsprechende systemd
-Unit-Datei vorliegen, die durch die Zeitgeber-Unit gesteuert wird. Anders gesagt, eine .timer
-Datei aktiviert und verwaltet die zugehörige .service
-Datei. Wird eine .service
-Datei mit einem Zeitgeber verwendet, muss die Datei keinen Abschnitt [Install]
enthalten, da der Dienst durch den Zeitgeber verwaltet wird.
19.7.3 Beispiel aus der Praxis #
Zur Veranschaulichung der Grundlagen von systemd
-Zeitgeber-Units soll ein Zeitgeber eingerichtet werden, der das Shell-Skript foo.sh
auslöst.
Im ersten Schritt erstellen Sie eine systemd
-Dienst-Unit, die das Shell-Skript steuert. Öffnen Sie hierzu eine neue Textdatei zum Bearbeiten und fügen Sie folgende Dienst-Unit-Definition hinzu:
[Unit] Description="Foo shell script" [Service] ExecStart=/usr/local/bin/foo.sh
Speichern Sie die Datei unter dem Namen foo.service
im Verzeichnis /etc/systemd/system/
.
Öffnen Sie dann eine neue Textdatei zum Bearbeiten und fügen Sie folgende Zeitgeberdefinition hinzu:
[Unit] Description="Run foo shell script" [Timer] OnBootSec=5min OnUnitActiveSec=24h Unit=foo.service [Install] WantedBy=multi-user.target
Der Abschnitt [Timer]
im obigen Beispiel gibt an, welcher Dienst (foo.service
) zu welchem Zeitpunkt ausgelöst werden soll. In diesem Fall gibt die Option OnBootSec
einen monotonen Zeitgeber an, der den Dienst fünf Minuten nach Systemstart auslöst, während die Option OnUnitActiveSec
den Dienst 24 Stunden nach Aktivierung des Dienstes auslöst (der Zeitgeber löst den Dienst also einmal täglich aus). Die Option WantedBy
gibt schließlich an, dass der Zeitgeber gestartet werden soll, sobald das System das Mehrbenutzerziel erreicht hat.
Anstelle eines monotonen Zeitgebers können Sie mit der Option OnCalendar
einen Echtzeit-Zeitgeber angeben. Die folgende Echtzeit-Zeitgeberdefinition löst die zugehörige Dienst-Unit einmal wöchentlich aus, beginnend am Montag um 12:00 Uhr.
[Timer] OnCalendar=weekly Persistent=true
Die Option Persistent=true
gibt an, dass der Dienst sofort nach Aktivierung des Zeitgebers ausgelöst wird, falls der Zeitgeber die letzte Startzeit versäumt hat (z. B. weil das System ausgeschaltet war).
Mit der Option OnCalendar
können außerdem bestimmte Zeitpunkte (Datum und Uhrzeit) für die Auslösung eines Dienstes im folgenden Format definiert werden: Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde
. Im folgenden Beispiel wird ein Dienst täglich um 5:00 Uhr gestartet:
OnCalendar=*-*-* 5:00:00
Ein Sternchen bezeichnet einen beliebigen Wert und mögliche Werte können durch Komma getrennt aufgelistet werden. Verwenden Sie zwei durch .. getrennte Werte, um einen zusammenhängenden Bereich anzugeben. Im folgenden Beispiel wird ein Dienst an jedem Freitag im Monat um 18:00 Uhr gestartet:
OnCalendar=Fri *-*-1..7 18:00:00
Soll ein Dienst zu verschiedenen Zeiten ausgelöst werden, können Sie mehrere OnCalendar
-Einträge angeben:
OnCalendar=Mon..Fri 10:00 OnCalendar=Sat,Sun 22:00
Im obigen Beispiel wird ein Dienst an Wochentagen um 10:00 Uhr und am Wochenende um 22:00 Uhr ausgelöst.
Wenn Sie die Zeitgeber-Unit-Datei bearbeitet haben, speichern Sie sie unter dem Namen foo.timer
im Verzeichnis /etc/systemd/system/
. Prüfen Sie die erstellten Unit-Dateien mit folgendem Kommando:
>
sudo
systemd-analyze verify /etc/systemd/system/foo.*
Wenn das Kommando keine Ausgabe zurückgibt, haben die Dateien die Überprüfung erfolgreich bestanden.
Starten Sie den Zeitgeber mit dem Kommando sudo systemctl start foo.timer
. Soll der Zeitgeber beim Starten aktiviert werden, führen Sie das Kommando sudo systemctl enable foo.timer
aus.
19.7.4 Verwalten von systemd
-Zeitgebern #
Da Zeitgeber wie normale systemd
-Units behandelt werden, können Sie sie mit systemctl
verwalten. Sie können einen Zeitgeber mit systemctl start
starten, mit systemctl enable
aktivieren usw. Außerdem können Sie mit dem Kommando systemctl list-timers
alle aktiven Zeitgeber auflisten. Mit dem Kommando systemctl list-timers --all
werden alle Zeitgeber aufgelistet, auch wenn sie inaktiv sind.
19.8 Weitere Informationen #
Weitere Informationen zu systemd
finden Sie in folgenden Online-Quellen:
- Startseite
systemd
für AdministratorenLennart Pöttering, einer der
systemd
-Autoren, hat eine Serie von Blogeinträgen verfasst. (Zum Zeitpunkt, als dieses Kapitel verfasst wurde, standen bereits 13 Einträge zur Verfügung.) Diese sind unter http://0pointer.de/blog/projects zu finden.