Systemd wird inzwischen von den meisten modernen Linux-Distributionen als Init-System genutzt, das für die Verwaltung aller Dienste zuständig ist. Leider werden die Möglichkeiten von systemd sehr unterschätzt, weshalb ich ein paar kleine Einblicke über die Möglichkeiten des modernen Init-Systems geben möchte. Wir starten mit der, meiner Meinung nach, nützlichsten Einsatzmöglichkeit: systemd-timer!
Timer anzeigen
Um die aktuell konfigurierten Timer anzuzeigen, kann man das kleine Tool systemctl list-timers nutzen.
root@web1: ~ # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2017-01-23 00:00:00 CET 11h left Sun 2017-01-22 12:00:01 CET 14min ago certbot.timer certbot.service Mon 2017-01-23 11:08:11 CET 22h left Sun 2017-01-22 11:08:11 CET 1h 6min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Wie man an der Ausgabe meines Webservers sehen kann, werden hier zwei Jobs ausgeführt: die Erneuerung meiner SSL-Zertifikate und die Entfernung nicht mehr benötigter Tempfiles durch systemd.
Timer-Unit
Um eigene Timer anzulegen genügt es, ein einfaches Text-File unter /etc/systemd/system/ zu erstellen. Der Dateiname kann frei gewählt werden, muss aber auf .timer enden. Eine einfache Timer-Unit sieht so aus:
[Unit] Description=Run certbot twice daily [Timer] OnCalendar=*-*-* 00,12:00:00 RandomizedDelaySec=3600 Persistent=true [Install] WantedBy=timers.target
Die Optionen sind eigentlich relativ selbsterklärend, trotzdem möchte ich kurz auf den Timer-Abschnitt eingehen. Die Abschnitte Unit und Install sind identisch mit den Abschnitten der Service Units.
- OnCalendar – durch die hier angegebene Option wird der Job alle 12 Stunden ausgeführt
- RandomizedDelaySec – diese Option gibt an, dass systemd mit der Ausführung des Jobs zufällig bis zu 3600 Sekunden warten soll (sehr hilfreich, um Überlastungen bei z.B. Backups zu vermeiden)
- Persistent – bewirkt, dass versäumte Jobs – z.B. weil der Rechner ausgeschaltet war – beim nächsten Start nachgeholt werden
Eine komplette Liste aller möglichen OnCalendar-Optionen inklusive Beispielen findet man in der systemd-Dokumentation.
Service-Unit
Jeder Timer-Unit muss eine entsprechende, gleichnamige .service-Datei beiliegen, die den auszuführenden Prozess beschreibt. Für den angelegten certbot-Timer sieht die .service-Datei so aus:
[Unit] Description=Let's Encrypt renewal [Service] Type=oneshot ExecStart=/usr/bin/certbot renew --quiet --agree-tos
Diese Datei ist, denke ich, selbsterklärend. Type gibt an, dass das Skript nur einmalig ausgeführt wird, ExecStart gibt das zu startende Skript inklusive Optionen an – in diesem Fall eben den certbot.
Timer aktivieren
Neu angelegte systemd-timer müssen, wie auch service-units erst durch systemctl enable dauerhaft aktiviert werden. Um Änderungen an bereits aktivierten Timern einzulesen, genügt es, den Timer mit systemctl reenable –now certbot.timer neu zu aktivieren.
Fazit
systemd-Timer sind nach kurzer Gewöhnung sehr einfach einzusetzen, auch wenn es etwas mehr Arbeit ist, als einen einfachen Cronjob anzulegen. Der größte Vorteil gegenüber Cron ist aber relativ eindeutig: man kann systemd-timer zeitlich viel genauer steuern, als es mit Cronjobs möglich ist.
Wichtig: systemd versendet die Ausgabe von gestarteten Timern nicht automatisch per E-Mail, wie es Cron tut. Um dies zu korrigieren, muss man die Mailfunktion bestenfalls direkt in das zu startende Skript einbauen oder eine Lösung wie die aus dem ArchWiki nutzen.