Geben Sie einem kleinen geplanten Job eine klare Grenze.

Eine endliche Arbeitseinheit definieren

Stellen Sie sich ein persönliches Werkzeug vor, das aus seinen vorhandenen Datensätzen eine kleine tägliche Zusammenfassung neu erstellt. Der Job liest eine begrenzte Datenmenge, bereitet eine Ersatzzusammenfassung vor und beendet sich. Er ist kein Webserver und sollte zwischen geplanten Starts nicht weiterlaufen. Notieren Sie Eingabe, Ziel, erwartete Dauer und was als Erfolg zählt, bevor Sie einen Timer hinzufügen.

Das Beispiel setzt einen Linux-Host mit systemd und util-linux voraus flock, Administratorzugriff und ein bestehendes unprivilegiertes Konto und eine Gruppe namens fieldjob. Sein geprüftes Job-Skript liegt unter /opt/field-jobs/build-summary und läuft im Vordergrund. Ein Administrator besitzt dieses Skript; das Job-Konto kann es lesen und ausführen, aber seinen Code nicht umschreiben. Prüfen Sie ausführbare Pfade auf Ihrer Distribution. Dies sind Vorlagen, kein installierter OffVPS-Planungsdienst.

Das Skript muss einen Fehler mit einem Nicht-Null-Exit-Status melden. Entwerfen Sie es für Ersatzdateien so, dass es ein temporäres Ergebnis vorbereitet und prüft, bevor es veröffentlicht wird. Verwenden Sie für Datenbankarbeiten den Transaktions- oder Deduplizierungsmechanismus der Datenbank. Ein Lock allein kann eine teilweise abgeschlossene Aufgabe nicht sicher wiederholbar machen.

Eine Zeitzone und eine Richtlinie für verpasste Läufe wählen

Unsere Zusammenfassung ist einmal täglich um 02:15 UTC nützlich. Verwenden Sie eine explizite Zone, damit die lokale Zeitzone der Maschine keine unsichtbare Abhängigkeit ist. UTC vermeidet in diesem Beispiel saisonale Uhrzeitänderungen; eine an lokale bürgerliche Zeit gebundene Geschäftsaufgabe braucht eine benannte Zeitzone und eine Prüfung ihres Sommerzeitverhaltens. Die systemd-Zeitreferenz beschreibt Kalenderausdrücke.

Speichern Sie diese Vorlage als /etc/systemd/system/field-summary.timer auf dem vorgesehenen VPS nach Prüfung der Namen:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true fordert eine Nachholaktivierung nach einer inaktiven Phase an, wenn ein Kalenderereignis verpasst wurde. Es spielt keinen separaten Lauf für jeden verpassten Tag erneut ab. Ein Timer startet auch keine weitere Instanz desselben Dienstes, während dieser Dienst aktiv ist. Diese Verhaltensweisen und die Planungsgenauigkeit sind abgedeckt durch die Timer-Referenz. Entscheiden Sie, ob eine verspätete Zusammenfassung nützlich ist, bevor Sie Catch-up aktivieren.

Dienstbenutzer, Zustandsverzeichnis und Lock setzen

Die passende /etc/systemd/system/field-summary.service beschreibt die Arbeit:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot eignet sich für einen Befehl, der abgeschlossen wird; ein expliziter Start-Timeout begrenzt dieses Beispiel. Fügen Sie RemainAfterExit=yes nicht zu einem Dienst hinzu, der nach jedem Lauf inaktiv werden muss. Siehe systemds Dienstsemantik. Setzen Sie einen Timeout anhand der Arbeitslast und machen Sie Unterbrechungen sicher, statt anzunehmen, dass fünf Minuten für jeden Job passen.

Für diesen Systemdienst StateDirectory erstellt das genannte Verzeichnis unter /var/lib mit Dienst-Eigentümerschaft. Arbeitsverzeichnis, Benutzer, Berechtigungen und Ausgabeziele sind explizit; das Skript sollte absolute Pfade für seine eigenen Werkzeuge und Daten verwenden. Umgebungs- und Verzeichnisregeln sind dokumentiert in systemds Ausführungsreferenz. Legen Sie keine geheimen Werte in Befehlszeilenargumente und protokollieren Sie sie nicht.

Der nicht blockierende flock -Wrapper beendet sich mit Code 75, wenn eine andere kooperierende Ausführung dieses Lock hält. Wir lassen das bewusst als sichtbaren, zu prüfenden Fehler stehen, statt eine übersprungene Zusammenfassung als abgeschlossene Arbeit zu behandeln. Alle manuellen Aufrufe müssen denselben Wrapper und Lock-Pfad verwenden. Löschen Sie keine Lock-Datei, um einen laufenden Job freizugeben: eine neue Datei kann ein separates Lock erzeugen. Dies ist ein lokales Dateisystemmuster, kein verteiltes Lock über VPS-Instanzen hinweg. Siehe das upstream flock-Handbuch.

Die Dateien prüfen, dann einen kontrollierten Lauf versuchen

Verwenden Sie für den ersten Lauf einen wegwerfbaren Datensatz mit deaktivierten ausgehenden E-Mails, Zahlungen und anderen Nebenwirkungen. Prüfen Sie vor der Aktivierung den geparsten Zeitplan und die Unit-Dateien auf diesem Testhost:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

Diese Prüfungen können Unit- und Zeitplanfehler erkennen; sie können nicht belegen, dass Ihr Skript eine korrekte Zusammenfassung erzeugt. Die systemd-analyze-Referenz erklärt ihren Umfang. Laden Sie nach der Korrektur von Fehlern die geprüften Dateien und starten Sie den Testjob explizit:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

Erwarte einen endlich erfolgreichen Aufruf und ein geprüftes Ausgabeartefakt; ein erfolgreicher Oneshot kann danach inaktiv angezeigt werden. Untersuche das Ergebnis selbst, einschließlich des Verhaltens bei leerer Eingabe. Mache einen nur zum Test dienenden Lauf absichtlich langsam, rufe denselben gesperrten Befehl zweimal auf dem Testdatensatz auf und stelle sicher, dass der zweite Aufruf eine Sperrkonkurrenz meldet, ohne ein konkurrierendes Ergebnis zu schreiben.

Den Zeitplan erst nach Prüfung seiner Ausgabe aktivieren

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

Prüfe die nächste geplante Zeit und überprüfe dann das erste geplante Ergebnis. Halte Startzeit, Endezeit, Anzahl verarbeiteter Elemente und Ergebnis in den Protokollen des Skripts fest. Ein fehlender Erfolgseintrag ist ein Grund zur Prüfung, kein Beweis, dass der Job ausgeführt wurde. Beachte die Timer- und Aktivierungsbefehle von systemctl.

Um zukünftige Starts zu pausieren, verwende sudo systemctl disable --now field-summary.timer. Das beendet keinen bereits laufenden Dienst. Wenn eine Unterbrechung nötig ist, stelle zuerst fest, ob sein aktueller Schreibvorgang sicher gestoppt werden kann. Wenn die Arbeit wächst, überprüfe Dauer, Wiederholungsversuche und externe API-Limits; mehrere Maschinen erfordern eine gemeinsame Koordination. Fahre fort mit dem Szenario für persönliche Tools und einer Wiederherstellungsübung für die Daten, die diese Automatisierung pflegt.