Linux-Tutorial / Aufgaben mit cron und systemd-Timern planen

Cron eignet sich für einfache Zeitpläne, während systemd-Timer geplante Arbeiten mit dem Dienstestatus und Protokollen integrieren. Überprüfen Sie den interpretierten Zeitplan, die tatsächliche Ausführung, die Ausgabe und Fehler separat, anstatt die Registrierung als Beweis für den Erfolg zu behandeln.

Testen Sie einen Befehl direkt, wie in Bash-Skript-Grundlagen, bevor Sie ihn planen. Überprüfen Sie das Logout-Verhalten des systemd-Managers des Benutzers und die Linger-Konfiguration in der tatsächlichen VM; allein das Registrieren eines Timers garantiert keine fortgesetzte Ausführung.

Systemkonfigurationsübungen verwenden eine herkömmliche Ubuntu 26.04 LTS oder Rocky Linux 9 VM als Referenzumgebung. Container, WSL und andere Versionen können sich in Dienst- und Paketkonfiguration unterscheiden. Bereiten Sie die Konsolenwiederherstellung vor und zeichnen Sie Ihre Versionen mit der virtuellen Maschinen-Einrichtungslektion auf.

Wählen Sie zwischen cron und einem systemd-Timer

Kriterium cron systemd-Timer
Konfiguration Zeitfelder plus ein Befehl Separate Timer- und Serviceeinheiten
Verifizierung Ausgabe- und distributionsspezifische Protokolle Service-Zustand und Journal
Umgebung Unterschiedlich von einer interaktiven Shell Für die Einheit definierte Umgebung
Verpasste Ausführungen Traditionelles Cron holt im Allgemeinen nicht auf Betrachten Sie OnCalendar mit Persistent

Dämonnamen und Pakete variieren: Ubuntu verwendet üblicherweise cron, während Rocky Linux cronie und crond verwendet. Das Timer-Beispiel erfordert einen verfügbaren systemd-Benutzermanager. Unterscheiden Sie das Verhalten von traditionellem Cron von ergänzenden Werkzeugen wie anacron.

Lesen Sie Cron-Felder und Ausführungskontext

crontab -e bearbeitet den Zeitplan des aktuellen Benutzers. Eine Benutzer-Crontab hat Minute, Stunde, Tag des Monats, Monat und Wochentag Felder vor dem Befehl. Das Beispiel läuft täglich um 02:15; ersetzen Sie /home/USER durch tatsächliche absolute Pfade. System-/etc/crontab-Einträge enthalten auch ein Benutzerfeld.

15 2 * * * /bin/bash /home/USER/bin/job.sh >> /home/USER/job.log 2>&1

Cron übernimmt nicht den PATH, das Arbeitsverzeichnis und die Variablen Ihres interaktiven Terminals unverändert. Verwenden Sie absolute Pfade, legen Sie Arbeitsverzeichnisse explizit fest und halten Sie Geheimnisse aus dem Crontab-Text fern. Das Einschränken sowohl von Tag des Monats als auch Wochentag kann eine OR-artige Übereinstimmung auslösen. Überprüfen Sie die Zeitzone, Sommerzeitregelung und Prozentzeichenregeln der Implementierung.

Erstellen Sie vollständige Benutzer-Service- und Timer-Einheiten

Überschreiben Sie keine Einheiten mit diesen Namen, wenn sie bereits existieren. Das Beispiel schreibt jede Minute einen Zeitstempel in das Benutzerjournal, ohne einen Root-Dienst zu erstellen. Bestätigen Sie /usr/bin/date mit command -v date und passen Sie ExecStart an, wenn Ihre Installation abweicht.

mkdir -p "$HOME/.config/systemd/user"
cat > "$HOME/.config/systemd/user/linux-course-clock.service" <<'EOF'
[Unit]
Description=Linux course timestamp exercise

[Service]
Type=oneshot
ExecStart=/usr/bin/date --iso-8601=seconds
EOF
cat > "$HOME/.config/systemd/user/linux-course-clock.timer" <<'EOF'
[Unit]
Description=Run the course clock every minute

[Timer]
OnCalendar=*-*-* *:*:00
AccuracySec=1s
Persistent=true

[Install]
WantedBy=timers.target
EOF
systemd-analyze calendar '*-*-* *:*:00'
systemctl --user daemon-reload
systemctl --user enable --now linux-course-clock.timer

Ein Timer aktiviert den Dienst mit dem entsprechenden Basisnamen. OnCalendar definiert einen Kalenderplan; AccuracySec steuert die Zusammenführungs-Toleranz, keine harte Echtzeitgarantie. Mit Persistent=true kann ein überfälliger Kalendertimer bei der Reaktivierung ausgelöst werden, aber verpasste Ereignisse werden nicht alle einzeln wiederholt.

Überprüfen Sie den nächsten Trigger und das tatsächliche Ergebnis

systemctl --user list-timers --all linux-course-clock.timer
systemctl --user status linux-course-clock.timer
journalctl --user -u linux-course-clock.service --since "5 minutes ago" --no-pager
systemctl --user show linux-course-clock.service -p Result -p ExecMainStatus
timedatectl

Überprüfen Sie den nächsten Trigger, und prüfen Sie dann die Journalausgabe nach ein oder zwei Minuten. Ein One-Shot-Dienst kann nach einem erfolgreichen Lauf inaktiv sein, also lesen Sie auch Result und ExecMainStatus. Verwenden Sie timedatectl, um die Serverzeitzone und die Uhrzeitsynchronisation mit dem vorgesehenen Geschäftszeitplan zu vergleichen.

Für Jobs, die einen Logout überdauern müssen, prüfen Sie den Lebenszyklus des Benutzermanagers und die örtliche Linger-Richtlinie. Das Aktivieren eines Timers stellt kein Verhalten über jeden Logout- oder Neustartfall hinweg sicher. Timer in Produktionssystemen benötigen ein gezieltes Servicekonto, Pfade, Berechtigungen und Ressourcenlimits.

Kontrollieren Sie Überschneidungen, prüfen Sie Fehler und entfernen Sie die Übung

Ein Cron-Job, der sein Intervall überschreitet, kann sich mit dem nächsten Aufruf überschneiden; erwägen Sie gegebenenfalls eine Sperre wie flock. Ein Timer erstellt nicht automatisch eine zweite gleichzeitige Instanz desselben Dienstes, wenn dieser bereits aktiv ist. Andere Einheiten oder manuelle Aufrufe können dennoch Ressourcen teilen, daher bleiben Anforderungen an die gleichzeitige Nutzung auf Anwendungsebene wichtig.

systemctl --user disable --now linux-course-clock.timer
rm -- "$HOME/.config/systemd/user/linux-course-clock.timer" "$HOME/.config/systemd/user/linux-course-clock.service"
systemctl --user daemon-reload
systemctl --user list-timers --all linux-course-clock.timer

Die Entfernung betrifft nur die beiden Laboreinheiten. Wenn Sie den Beispiel-Cron-Eintrag hinzugefügt haben, entfernen Sie nur diesen Eintrag mit crontab -e und prüfen Sie ihn mit crontab -l; löschen Sie nicht den gesamten Zeitplan. Die Produktionsautomatisierung benötigt auch eine Möglichkeit, Fehler oder Nichtausführungen zu erkennen und sich davon zu erholen.

Offizielle Referenzen