systemd-Timer sind die moderne Alternative zu cron. Statt einer einzigen Crontab-Zeile besteht ein Timer aus zwei Units — einem Timer und einem Service — und bringt Logging, Persistence und Dependencies frei Haus mit. Wer auf einem aktuellen Linux-System neue periodische Jobs einrichtet, sollte den Vergleich kennen, bevor die nächste Zeile in der Crontab landet.
Was systemd-Timer sind
Ein systemd-Timer ist eine Unit-Datei mit der Endung .timer, die festlegt, wann etwas passieren soll. Die eigentliche Arbeit erledigt eine zugehörige .service-Unit, die der Timer beim Auslösen startet. Beide gehören als Paar zusammen — der Timer alleine tut nichts, das Service alleine wird nie automatisch ausgeführt.
systemd-Timer sind eine Komponente von systemd, dem Init- und Service-Manager moderner Distributionen. Sie laufen entweder system-weit (verwaltet von PID 1) oder pro User (verwaltet von einer User-Instanz von systemd). Damit decken sie denselben Anwendungsbereich ab wie cron, integrieren sich aber tief in das systemd-Ökosystem.
Vergleich systemd-Timer vs. cron
| Aspekt | systemd-Timer | cron |
|---|---|---|
| Logging | zentral via journalctl -u name.service | Mail an User oder eigenes Logfile |
| DST / Zeitumstellung | sauber, mit Wall-Clock-Logik | tricky, doppelte oder ausgelassene Läufe |
| Persistence | ja, mit Persistent=true werden verpasste Läufe nachgeholt | nein, ein verpasster Job ist verloren |
| Dependencies | After=, Wants=, Requires= zu anderen Units | keine, jede Crontab-Zeile steht für sich |
| Genauigkeit | bis Sub-Sekunde via OnUnitActiveSec= | Granularität von einer Minute |
| User-Timer | pro User mit eigener systemd-Instanz | pro User via eigener Crontab |
| Boot-Trigger | OnBootSec=, OnStartupSec= | @reboot-Direktive |
| Status-Übersicht | systemctl list-timers zeigt alle Timer mit nächstem Lauf | kein zentrales Tool, nur Crontabs einzeln lesen |
Mehr zu cron im Artikel cron und crontab.
Mini-Beispiel
Ein vollständiger User-Timer besteht aus zwei Dateien unter ~/.config/systemd/user/. Erst die Service-Unit, die definiert, was ausgeführt wird:
[Unit]
Description=Tägliches Backup
[Service]
Type=oneshot
ExecStart=/home/me/backup.shDann die Timer-Unit, die festlegt, wann das Service starten soll:
[Unit]
Description=Tägliches Backup einplanen
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.targetAktiviert und sofort gestartet wird der Timer mit einem einzigen Befehl:
systemctl --user enable --now backup.timerDamit läuft das Backup ab sofort einmal täglich. Persistent=true sorgt dafür, dass ein verpasster Lauf nach dem nächsten Login nachgeholt wird.
Wann was?
cron und systemd-Timer schließen sich nicht aus, haben aber jeweils typische Stärken. Eine grobe Daumenregel hilft bei der Entscheidung:
- cron bleibt die schnelle Lösung für simple, einzeilige Jobs und für Legacy-Systeme, wo systemd nicht der Standard ist. Eine einzige Crontab-Zeile ist schneller geschrieben als zwei Unit-Dateien.
- systemd-Timer spielen ihre Stärken aus, sobald es um Production geht: Jobs mit Dependencies zu anderen Services, Persistence auf Laptops und VMs, die nicht 24/7 laufen, vollständige Logs im Journal und feinere Zeitsteuerung.
In Container-Umgebungen lohnt der Blick auf den Init-Prozess: Wo systemd nicht läuft, fallen Timer flach.
Weiterführend im systemd-Kapitel
Dieser Artikel ist bewusst als kompakter Brücken-Artikel gehalten. Die ausführliche Behandlung von Unit-Syntax, dem vollständigen OnCalendar-Format, Drop-Ins, Templates und der Integration mit systemctl und journalctl folgt im eigenen systemd-Kapitel. Für den Alltag mit periodischen Jobs reichen die hier gezeigten Bausteine in den meisten Fällen aus.
Hinweise
Timer und Service gehören immer als Paar
Eine Timer-Unit ohne zugehörige Service-Unit ist sinnlos — der Timer hat dann nichts zum Auslösen. Per Konvention tragen beide denselben Namen mit unterschiedlicher Endung (backup.timer und backup.service). Abweichende Zuordnungen sind möglich über Unit= im [Timer]-Abschnitt, sind aber unüblich und erschweren die Übersicht.
Logs und Status zentral abrufen
journalctl -u backup.service zeigt alle Ausgaben und Exit-Codes des Service. systemctl --user list-timers listet alle aktiven Timer mit ihrem nächsten Lauf, der letzten Ausführung und der zugehörigen Unit. Das ersetzt das manuelle Durchsuchen von Crontabs und Logfiles vollständig.
OnCalendar-Format ist maechtig
Neben Aliasen wie daily, weekly oder hourly versteht OnCalendar= ein eigenes Format — etwa Mon..Fri *-*-* 09:00:00 für werktags um neun Uhr oder *-*-* *:0/15:00 für alle 15 Minuten. Die volle Syntax dokumentiert man systemd.time.
User-Timer brauchen Lingering
Standardmäßig läuft die User-Instanz von systemd nur, solange der Nutzer eingeloggt ist — beim Logout enden auch die User-Timer. Mit loginctl enable-linger username bleibt die User-Instanz dauerhaft aktiv, und User-Timer laufen unabhängig von einer Anmeldung weiter. Pflicht für alle Server-Setups mit User-Timern.
Container brauchen ein systemd-Init
In klassischen Docker-Containern ohne systemd als PID 1 funktionieren weder systemctl noch Timer. Wer Timer in Containern braucht, nutzt entweder ein systemd-fähiges Base-Image (Fedora, openSUSE) oder bleibt bei cron. Die meisten Container-Images sind absichtlich minimal und setzen auf einen einzigen Vordergrundprozess.
Weiterführende Ressourcen
Externe Quellen
- man systemd.timer (man7.org) — vollständige Referenz aller Timer-Optionen
- man systemd.time (man7.org) — die komplette Syntax von
OnCalendarund Zeitspannen - man systemd.service (man7.org) — Referenz für die zugehörige Service-Unit
- Arch Wiki: systemd/Timers — kompakter Überblick mit Beispielen
- Arch Wiki: systemd/User — Hintergrund zu User-Instanzen und Lingering
Verwandte Artikel
- cron und crontab — der klassische Job-Scheduler unter Linux
- at und batch — einmalige Jobs zu festem Zeitpunkt einplanen
- Prozess-Modell — PID, PGID und Sessions als Fundament aller Scheduler
- systemd Übersicht — der ausführliche Einstieg ins systemd-Kapitel
- Shell-Scripting Grundlagen — Skripte schreiben, die per Timer oder cron laufen