Seit Ubuntu 15.04 ist systemd tief im System verankert und bietet eine klare Alternative zu klassischen Cron-Jobs. Timer units steuern, wann ein Job läuft, und service units beschreiben, was ausgeführt wird. Die Trennung von Zeitplan und Logik macht Wartung und Debugging einfacher.
Timer erlauben absolute Zeitangaben via OnCalendar und relative Angaben wie OnBootSec oder OnUnitActiveSec. Logs landen konsistent im journald, was Fehlersuche deutlich vereinfacht. Abhängigkeiten lassen sich über Requires und Conflicts regeln.
Aktivieren oder Deaktivieren klappt per systemctl, statt zeilenweise Cron-Dateien zu bearbeiten. Transiente Jobs können mit systemd-run erstellt werden und erscheinen unter /run/systemd/transient.
Kurze Beispiele:
Bash: sudo systemctl enable myjob.timer
Shell (transient): systemd-run --on-calendar='*-*-* 03:00:00' --unit=myrun sleep 10
Dieses Kapitel gibt einen kompakten Überblick über die Aufgaben, die sich mit dieser Kombination effizienter automatisieren lassen. Description-Felder und klare Statusausgaben helfen, die Wartbarkeit zu verbessern.
Warum Timer Units Cron ablösen: Überblick, Nutzen und Architektur
Moderne Zeitsteuerung nutzt timer units, um Cron-Aufgaben zuverlässiger und transparenter zu machen.
Vorteile gegenüber Cron
Timer units starten service units zu definierten Zeiten und trennen das Wann vom Was. So entsteht eine klare Architektur, die Cronjobs strukturiert ersetzt.
Abhängigkeiten wie Requires und Conflicts verhindern Überschneidungen. Logs landen zentral im journald, was Fehlersuche und Compliance vereinfacht.
Grundlagen der Units
Eine service unit beschreibt die Aufgabe; die timer unit regelt das Intervall oder den Kalender. Die Endung .service bzw. .timer ist verpflichtend und macht den Typ eindeutig.
Unit-Dateien liegen in Verzeichnissen wie /etc/systemd/system, /etc/systemd/user oder /etc/systemd/network. Admins behalten so Kontrolle über eigene Deployments.
Kalenderbasierte OnCalendar-Angaben sind lesbarer als Cron-Syntax. Monotone Timer wie OnBootSec oder OnUnitActiveSec verhindern doppelte Starts. Aktivieren erfolgt mit enable, sofortiges Starten mit start.
systemd Timer Ubuntu einrichten: Schritt-für-Schritt von .service bis .timer
Ein sauberes Setup beginnt mit klaren Dateinamen und dem richtigen Ort. Legen Sie eigene Units in /etc/systemd/system ab und achten Sie auf die Endung .service sowie .timer. Ein konsistenter Name wie backup.service und backup.timer macht Verwaltung einfach.
Dateistruktur und Service Unit
Die service unit braucht mindestens Description und ein ExecStart. Optional setzen Sie User, um Rechte zu begrenzen. Halten Sie die Syntax kurz: Pfad zum Skript in ExecStart, Parameter getrennt.
Timer Unit, Sektionen und Kalender
Eine timer unit enthält [Unit], [Timer] und [Install]. Verknüpfen Sie mit Unit=backup.service und WantedBy=timers.target. Für absolute Zeitpunkte nutzen Sie OnCalendar, für relative Intervalle OnBootSec, OnStartupSec, OnActiveSec, OnUnitActiveSec und OnUnitInactiveSec.
Verlässlichkeit, Genauigkeit und Aktivierung
Setzen Sie Persistent=true, wenn verpasste calendar-Ereignisse nachgeholt werden sollen. Passen Sie AccuracySec und RandomizedDelaySec, um Genauigkeit und Lastverteilung zu steuern.
Nach dem Anlegen oder Ändern immer systemctl daemon-reload ausführen. Aktivieren Sie den Zeitplan mit systemctl enable –now backup.timer oder starten Sie getrennt mit start. Prüfen Sie Status mit systemctl status backup.timer backup.service.
Für Ad‑hoc-Jobs nutzen Sie systemd-run –on-calendar –unit=meine.task; die transienten Einträge finden Sie unter /run/systemd/transient oder /run/user/<uid>/systemd/transient.
Praxisbeispiele: Kalender-Syntax, On-Boot-Runs und periodische Aufgaben
Praxisnahe Beispiele zeigen, wie calendar-Ausdrücke und relative Optionen wiederkehrende aufgaben zuverlässig auslösen.
Kalender-Beispiele
Nutzen Sie OnCalendar=Mon-Fri *-*-* 12:00:00, um eine service unit an Werktagen zur Mittagsminute zu starten.
Komplexe calendar-Ausdrücke wie Thu,Fri 2016-*-1,5 11:12:13 erlauben Monatsmuster und kombinierte Bedingungen für präzise reports.
Monotone Abläufe nach dem Systemstart
Setzen Sie OnBootSec=30min für den ersten Start nach dem systemstart.
Für wiederkehrende Intervalle empfiehlt sich OnUnitInactiveSec=10min oder OnUnitActiveSec, damit kein neuer trigger beginnt, solange ein Lauf noch aktiv ist.
Verwaltung im Alltag
Behalten Sie den Überblick mit systemctl list-timers und systemctl –user list-timers; ergänzen Sie –all, um inaktive timers zu sehen.
Stoppen Sie laufende Jobs mit sudo systemctl stop name_des_timers.timer und entfernen Sie automatische Starts mit sudo systemctl disable name_des_timers.timer.
Für Ad-hoc-Jobs per systemd-run vergeben Sie einen klaren name via –unit und denken Sie daran, beim Aufräumen sowohl .service als auch .timer zu stoppen.
Saubere Administration mit systemd: was Sie jetzt direkt umsetzen können
Mit wenigen Maßnahmen bringen Sie Ihre Zeitpläne in eine wartbare, auditfähige Form. Aktivieren Sie eine systemd timer mit enable –now, damit ein Job in wenigen minuten sofort läuft und dauerhaft startet.
Schreiben Sie eine klare service unit und verlinken Sie sie in der .timer. Nach Änderungen immer systemctl daemon-reload ausführen und Status mit systemctl status foo.timer foo.service prüfen.
Nutzen Sie Persistent=true, AccuracySec und RandomizedDelaySec, um Zuverlässigkeit und Lastverteilung zu verbessern. Für einmalige Aufgaben ist die option systemd-run praktisch; vergeben Sie einen sprechenden Namen via –unit.
Standardisieren Sie enable/disable für Boot-Verhalten, testen Sie in Staging und rollen Sie geprüfte timers in Produktion aus, damit das system langfristig stabil bleibt.
