Leitfaden zu Systemd-Timern: Cron-Jobs für zuverlässige Planung ersetzen

Jahrzehntelang war cron der De-facto-Standard für die Terminierung von Aufgaben auf Linux- und Unix-ähnlichen Systemen. Seine Einfachheit und Allgegenwart machten es sowohl für Administratoren als auch für Entwickler zu einem unverzichtbaren Werkzeug. Als sich Linux-Systeme jedoch weiterentwickelten, insbesondere mit dem Aufkommen von systemd als System- und Dienstemanager, wurden robustere und besser integrierte Planungsmechanismen verfügbar. systemd-Timer-Units (.timer-Dateien) bieten eine moderne, leistungsstarke und oft überlegene Alternative zu traditionellen cron-Jobs.

Dieser Leitfaden untersucht die Vorteile von systemd-Timern und erläutert, wie sie sich nahtlos in den Rest des systemd-Ökosystems integrieren. Wir führen Sie umfassend durch die Konfiguration von Timer- (.timer) und Service-Dateien (.service), sodass Sie robuste, reproduzierbare und leicht verwaltbare geplante Aufgaben erstellen können. Am Ende dieses Artikels werden Sie verstehen, warum systemd-Timer oft die bevorzugte Wahl für eine zuverlässige Aufgabenplanung in modernen Linux-Umgebungen sind.

Systemd-Timer verstehen

systemd-Timer sind systemd-Unit-Dateien, die steuern, wann andere systemd-Units, typischerweise service-Units, aktiviert werden. Im Gegensatz zu cron, das ein eigenständiger Daemon ist, sind systemd-Timer ein integraler Bestandteil des systemd-Init-Systems. Diese tiefe Integration bringt mehrere erhebliche Vorteile mit sich, insbesondere in Bezug auf Zuverlässigkeit, Protokollierung und Ressourcenverwaltung.

A systemd-Timer arbeitet immer in Verbindung mit einer anderen Unit, meistens einer service-Unit. Die .timer-Datei definiert, wann ein Ereignis auftreten soll, und die entsprechende .service-Datei definiert, welche Aktion ausgeführt werden soll, wenn dieses Ereignis ausgelöst wird. Diese klare Trennung der Verantwortlichkeiten macht systemd-Timer hochgradig modular und flexibel.

Wichtigste Vorteile von Systemd-Timern gegenüber Cron

Obwohl cron funktionsfähig ist, beheben systemd-Timer viele seiner Einschränkungen und bieten eine robustere und funktionsreichere PlanungsLösung:

Zuverlässigkeit und Persistenz: Wenn ein systemd-Timer mit Persistent=true konfiguriert ist und das System während eines geplanten Laufs ausgeschaltet ist, wird der zugehörige Dienst kurz nach dem erneuten Hochfahren des Systems ausgeführt. cron-Jobs hingegen verpassen ihre geplanten Läufe einfach, wenn das System nicht verfügbar ist.
Integration mit systemd: Timer profitieren von der leistungsstarken Protokollierung von systemd (über journalctl), dem Abhängigkeitsmanagement und der Ressourcensteuerung (cgroups). Dies bedeutet bessere Überwachung, klarere Fehlerberichterstattung und die Möglichkeit, komplexe Startsequenzen oder Ressourcengrenzen für geplante Aufgaben zu definieren.
Reproduzierbarkeit und Versionskontrolle: systemd-Unit-Dateien sind einfache Textdateien, die leicht in Versionskontrollsystemen gespeichert werden können. Dies ermöglicht reproduzierbare Bereitstellungen und eine einfachere Nachverfolgung von Änderungen an geplanten Aufgaben auf mehreren Systemen.
Ereignisbasierte Planung: Über die einfache zeitbasierte Planung hinaus können systemd-Timer relativ zum Systemstart (OnBootSec) oder nach der letzten Aktivierung einer Unit (OnUnitActiveSec) ausgelöst werden, was dynamischere Planungsoptionen bietet.
Flexible Zeitangaben: systemd bietet eine reichhaltige Auswahl an Kalenderereignis-Ausdrücken, die oft lesbarer und vielseitiger sind als die Syntax von cron, einschließlich stündlicher, täglicher, wöchentlicher und spezifischer Datums-/Zeitangaben.
Ressourcenmanagement und Abhängigkeiten: Von Timern gestartete systemd-Dienste erben die systemd-Umgebung, einschließlich cgroup-Einstellungen, und können Abhängigkeiten von anderen systemd-Units deklarieren (z. B. Warten, bis das Netzwerk oder eine Datenbank verfügbar ist, bevor sie ausgeführt werden).
Behandlung von Standardausgabe/Fehlerausgabe: systemd erfasst automatisch stdout und stderr von durch Timer gestarteten Diensten und leitet diese in das Systemprotokoll weiter, was das Debugging und die Überprüfung viel einfacher macht als bei der E-Mail-basierten Ausgabe von cron oder manueller Umleitung.

Systemd-Timer konfigurieren

Die Konfiguration eines systemd-Timers umfasst die Erstellung von zwei Unit-Dateien: einer Service-Unit (.service) und einer Timer-Unit (.timer). Diese Dateien werden typischerweise für systemweite Timer in /etc/systemd/system/ oder für benutzerspezifische Timer in ~/.config/systemd/user/ abgelegt.

1. Die Service-Unit (`.service`-Datei)

Die Service-Unit definiert den tatsächlichen Befehl oder das Skript, das ausgeführt werden soll. Es ist eine Standard-systemd-Service-Datei, die jedoch oft für die nicht-interaktive Ausführung und zur Durchführung einer bestimmten Aufgabe konzipiert ist.

Beispiel: /etc/systemd/system/mytask.service

[Unit]
Description=Mein geplanter Task-Dienst

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mytask.sh
User=myuser
Group=mygroup
# Optional: Ressourcen begrenzen
# CPUShares=512
# MemoryLimit=1G

[Install]
WantedBy=multi-user.target

Erklärung:

[Unit]: Enthält allgemeine Informationen über die Unit.
- Description: Eine für Menschen lesbare Beschreibung.
[Service]: Definiert die Service-spezifische Konfiguration.
- Type=oneshot: Zeigt an, dass der Dienst einen einzelnen Befehl ausführt und dann beendet wird. Dies ist üblich für geplante Aufgaben.
- ExecStart: Der auszuführende Befehl oder das Skript. Geben Sie den vollständigen Pfad an.
- User, Group: Definiert den Benutzer und die Gruppe, unter denen der Befehl ausgeführt wird. Führen Sie Aufgaben immer mit den geringstmöglichen Berechtigungen aus.
- CPUShares, MemoryLimit: (Optional) systemd ermöglicht es Ihnen, Ressourcengrenzen für Dienste festzulegen, indem cgroups genutzt werden.
[Install]: Definiert, wie die Unit aktiviert werden soll.
- WantedBy=multi-user.target: Obwohl vorhanden, ist dieser Abschnitt für timer-ausgelöste Dienste oft weniger kritisch, da die Timer-Unit selbst normalerweise die Aktivierung bestimmt. Er kann jedoch nützlich sein, wenn Sie den Dienst auch manuell aktivieren möchten oder ihn in andere systemd-Ziele integrieren möchten.

2. Die Timer-Unit (`.timer`-Datei)

Die Timer-Unit definiert, wann die entsprechende Service-Unit aktiviert werden soll. Sie muss denselben Namen wie ihr Service-Gegenstück haben (z. B. mytask.timer für mytask.service).

Beispiel: /etc/systemd/system/mytask.timer

[Unit]
Description=Führt mytask.service täglich aus

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=600
AccuracySec=1min

[Install]
WantedBy=timers.target