Systemd Baustein Timer

Aus Xinux Wiki
Version vom 17. Oktober 2026, 15:47 Uhr von Thomas.will (Diskussion | Beiträge) (Neue Seite: Baustein Timer)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen
Baustein ab Stufe Lernpfad
Timer Stufe 2 Übersicht

Einfach erklärt

  • Ein Timer ist eine Unit, die zu einer bestimmten Zeit eine andere Unit startet. Er ersetzt cron.
  • Zu jedem Timer gehört ein Service mit gleichem Namen: backup.timer startet backup.service.
  • Vorteil gegenüber cron: Jeder Lauf steht im Journal, man sieht den Erfolg in systemctl status, und verpasste Läufe können nachgeholt werden.

Das Wichtigste

  • Aktiviert wird der Timer, nicht der Service: systemctl enable --now backup.timer
  • Der Service bekommt meist Type=oneshot und keinen [Install]-Teil.
  • OnCalendar= für feste Zeiten, OnBootSec=/OnUnitActiveSec= für Abstände.
  • Persistent=true holt Läufe nach, die verpasst wurden, weil der Rechner aus war.

Ein Timer

  • /etc/systemd/system/backup.service
[Unit]
Description=Nächtliches Backup

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh
  • /etc/systemd/system/backup.timer
[Unit]
Description=Backup jede Nacht um 2 Uhr

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target
  • systemctl daemon-reload
  • systemctl enable --now backup.timer
  • systemctl list-timers backup.timer
  • RandomizedDelaySec= verteilt den Start zufällig. So greifen nicht alle Server gleichzeitig auf den Backup-Server zu.

Zeitangaben

OnCalendar= Bedeutung
hourly jede volle Stunde
daily täglich um 0 Uhr
weekly montags um 0 Uhr
*-*-* 02:00:00 täglich um 2 Uhr
Mon..Fri 07:30 werktags um 7:30
*-*-01 03:00 am Ersten jedes Monats um 3 Uhr
*:0/15 alle 15 Minuten
Abstände Bedeutung
OnBootSec=15min 15 Minuten nach dem Start
OnUnitActiveSec=1h eine Stunde nach dem letzten Lauf
OnActiveSec=30s 30 Sekunden nach dem Aktivieren des Timers
  • Zeitangaben testen, bevor man sie einträgt:
  • systemd-analyze calendar "Mon..Fri 07:30"
  Original form: Mon..Fri 07:30
Normalized form: Mon..Fri *-*-* 07:30:00
    Next elapse: Mon 2026-10-19 07:30:00 CEST

Anzeigen

Befehl Wirkung
systemctl list-timers alle aktiven Timer mit nächstem und letztem Lauf
systemctl list-timers --all auch die inaktiven
systemctl status backup.timer Zustand und nächster Lauf (Trigger)
journalctl -u backup.service Ausgabe der Läufe
systemctl start backup.service einmal sofort von Hand laufen lassen

Einmalig ohne Datei: systemd-run

  • In 10 Minuten einmal ausführen:
  • systemd-run --on-active=10min /usr/local/sbin/backup.sh
  • Morgen um 6 Uhr einmal:
  • systemd-run --on-calendar="2026-10-18 06:00" /usr/local/sbin/backup.sh
  • Diese Timer überleben keinen Neustart.

cron und Timer

cron systemd-Timer
Konfiguration eine Zeile zwei Dateien
Logs per Mail oder selbst umleiten automatisch im Journal
Verpasste Läufe weg mit Persistent=true nachgeholt
Abhängigkeiten keine After=, Requires= wie bei jeder Unit
Härtung keine alle Optionen aus Stufe 3

Beispiel: Zertifikate erneuern

  • Debian liefert mit dem Paket certbot schon einen fertigen certbot.timer mit.
  • systemctl list-timers certbot.timer
  • Wer einen eigenen schreibt, muss ihn mit enable --now aktivieren. Nur start ist nach dem Neustart weg.

Stolperfallen

  • Service aktiviert statt Timer. Dann läuft der Dienst einmal beim Start, nicht nach Zeitplan.
  • Timer geändert und nichts passiert: daemon-reload und systemctl restart backup.timer.
  • Trigger: n/a in status heißt: Der Timer hat keinen nächsten Termin. Meist ein Fehler in OnCalendar=, mit systemd-analyze calendar prüfen.
  • Zeitzone: OnCalendar= nutzt die lokale Zeit. Am Ende eine Zone angeben geht auch: *-*-* 02:00 UTC
  • Sicherheit: Timer sind ein beliebter Ort für Angreifer. systemctl list-timers --all gehört zu jeder Prüfung, siehe Stufe 3.

Aufgaben

Grundaufgaben

  1. Lassen Sie sich alle Timer anzeigen. Welcher läuft als Nächstes?
  2. Schreiben Sie einen Timer, der jede Minute das Datum an /tmp/zeit.log anhängt.
  3. Prüfen Sie mit journalctl, ob er läuft.
  4. Testen Sie mit systemd-analyze calendar: „jeden Sonntag um 23 Uhr“.

Für Schnelle

  1. Stellen Sie einen Ihrer cron-Jobs auf einen Timer um.
  2. Schalten Sie den Rechner zur Zeit des Timers aus und prüfen Sie, ob Persistent=true den Lauf nachholt.
  3. Starten Sie mit systemd-run einen Befehl in 2 Minuten und finden Sie den Timer in list-timers.

Weiter