Besser als Cronjobs: Timer Units mit systemd

Wer im Hosting auf Ubuntu Server setzt, sollte sich unbedingt eingehend mit den in systemd zur Verfügung stehenden Timer-Units auseinandersetzen. Denn diese tief in die Systemarchitektur integrierte Technologie ermöglicht es Administratoren, Cronjobs durch intelligente Kombinationen aus Timer Units und Service Units zu ersetzen. Damit lassen sich zahlreiche Probleme, die den Einsatz von Cron klassischerweise begleiten, sehr elegant umgehen. Wir fassen die wichtigsten Infos zu diesem spannenden Thema zusammen.

Was ist systemd?

Seit Ubuntu 15.04 ist der System- und Dienst-Manager systemd ein integraler Bestandteil des Betriebssystems. Aber das Init-System, das als erster Prozess gestartet wird und als Daemon im Hintergrund läuft, kann noch weitaus mehr, als nur Dienste für den Systemstart zu laden. Gerade in der Serveradministration lassen sich wichtige Aufgaben ganz hervorragend mithilfe des auf sogenannten Units basierenden systemd organisieren und zeitgesteuert starten. Von den insgesamt acht unterschiedlichen Arten von Units, sind für die Serveradministration vor allem zwei interessant: Service Units und Timer Units.

Was sind Service Units?

Service Units dienen dazu, Dienste wie zum Beispiel MySQL Server, Firewall oder Webserver zu definieren. Diese werden bekanntermaßen anhand der Kommandos stop, restart, start und reload gesteuert. War dies früher über

$ service

möglich, lautet die entsprechende Syntax seit Ubuntu 16.04

$ systemctl .service

Das Werkzeug systemctl dient dazu, systemd über die Kommandozeile zu steuern. Die Endung .service hinter dem Dienstnamen lässt erkennen, dass es hier um die Steuerung einer Service Unit geht. Service Units werden in drei Verzeichnissen abgelegt

• Eigene Service Units in /etc/systemd/system
• Dienste, die bestimmten Benutzern zur Verfügung gestellt werden, in /etc/systemd/user
• Und Dienste für die Netzwerk-Konfiguration in /etc/systemd/network

Und was sind Timer Units?

Timer Units dienen ausschließlich dazu, vorhandene Service Units zu starten. Dabei können monotonic timers verwendet werden, die also zum Beispiel in einem bestimmten Zeitabstand zum Boot-Vorgang oder, während das System läuft, in regelmäßigen Abständen auslösen. Bei der Verwendung von Timer Units muss beachtet werden, dass sie immer zunächst mit

$ systemctl enable .timer

aktiviert werden müssen, bevor man die entsprechenden Units auch starten kann.

Übrigens handelt es sich bei den Endungen der Dateinamen .service beziehungsweise .timer um erforderliche Angaben, mit denen spezifiziert wird, um welchen Typ es sich bei der jeweiligen Unit handelt.

Welche Vorteile ergeben sich gegenüber Cron?

Nun mag es im ersten Moment etwas befremdlich wirken, dass einfache Aufgaben auf dem Server, die sich mit einfachen Cronjobs doch schon immer recht gut verwalten ließen, nun mithilfe von ganz ähnlich funktionierenden Kombinationen aus Timer Units und Service Units organisiert werden sollen. Wozu dieser Aufwand? Was spricht für den Einsatz von systemd anstelle von Cronjobs? In einem Wort: allerhand. Hier die aus unserer Sicht wichtigsten Vorteile:

• Es lassen sich Abhängigkeiten zu anderen Services definieren, so dass entweder andere Services zuerst ausgeführt werden müssen, damit ein Dienst überhaupt gestartet wird (Requires), beziehungsweise ein Dienst nicht gestartet wird, sofern er in Konflikt mit einem anderen gerade laufenden Service geraten würde (Conflicts).
• Relative Zeitangaben sind möglich: Man kann Timer Units veranlassen, einen Dienst alle zehn Minuten, nachdem dieser ausgeführt wurde, zu starten. Damit gibt es keine überlappenden Dienstaufrufe mehr, die irgendwann dazu führen, die CPU zu blockieren, weil im Cron das Intervall zu niedrig angegeben wurde.
• Da es sich bei Timer Units selbst ebenfalls um Dienste handelt, können sie elegant aktiviert oder deaktiviert werden, während Cronjobs sich nur durch Auskommentieren oder Löschen deaktivieren lassen.
• Leichter verständliche Angabe von Zeitpunkten und -räumen im Vergleich zu Cron.

Units in systemd erlauben generell durch das „Description“-Feld Beschreibungen, die sich in Auflistungen anzeigen lassen. Damit wird der jeweilige Zweck der einzelnen Dienste leichter erkennbar – gerade wenn mehrere Personen an einem Server arbeiten.

• Zudem gibt es ein “Documentation”-Feld, in dem sich bei Bedarf ein Manual angeben lässt.

Mithilfe von systemd kann auf Benutzer (und -gruppen), Logging-Outputs (insbesondere über journald, die Service Unit für das Logging, und das dazugehörige Werkzeug journalctl) und weitere Systemressourcen zugegriffen werden. Cron dagegen verhält sich hier ärgerlich eigenwillig und verweigert entsprechende Anforderungen oftmals.

Und was lässt sich damit alles umsetzen?

Die Einsatzmöglichkeiten der Kombination von Timer Units und Service Units ist prinzipiell natürlich unbegrenzt. Und auch im Hinblick auf die Serveradministration lässt sich von klugem Testing über das automatische Auswerten von Logs bis hin zu umfangreichen Sicherheits-Aktivitäten eine Fülle von Aufgaben sehr intelligent und ganz ohne die oftmals mit dem Einsatz von Cronjobs einhergehenden Konflikte und Performance-Probleme automatisieren.

Ein kurzes Code-Beispiel

Die Syntax für Service Units und Timer Units in systemd ist ausgesprochen schlank und übersichtlich, was an dem folgenden kurzen Code-Beispiel deutlich wird.

Beispiel für eine Service Unit

Die Service Unit definiert den auszuführenden Dienst durch die Angabe des Benutzers und des Pfads zu dem Skript, das ausgeführt werden soll, um einen Shop einer automatisierten Funktionsprüfung zu unterziehen.

Datei: /etc/systemd/system/testshop.service

[Unit]
Description=Ein Shoptest.

[Service]
User=testuser
ExecStart=/path/to/testscript

Beispiel für eine dazugehörige Timer Unit

In der Timer Unit wird festgelegt, dass die oben definierte Service Unit jeweils 30 Minuten nach dem Booten und dann jeweils zehn Minuten nach ihrer letzten Aktivität gestartet werden soll.

Datei: /etc/systemd/system/testshop.timer

[Unit]
Description=Regelmäßiges Testen der Shops über den Browser.

[Timer]
OnBootSec=30min
OnUnitInactiveSec=10min
Persistent=true
User=testuser
Unit=testshop.service

[Install]
WantedBy=timers.target

Im Zusammenspiel sorgen beide Units also dafür, dass der Shop 30 Minuten nach dem Booten und dann im Abstand von jeweils zehn Minuten zur letzten Laufzeit auf Funktion überprüft wird.

In Vorbereitung: Praxisbeispiel Backup-Erstellung

Wir werden schon bald in einem weiteren Beitrag ein ausführlich kommentiertes Praxisbeispiel für die automatisierte Backup-Erstellung mithilfe der von systemd verarbeiteten Timer Units und Service Units liefern.