Das Symptom
Ein Backup-Timer mit OnCalendar=daily oder ein wöchentlicher Aufräumjob steht auf einem Laptop oder einem Rechner, der nachts aus ist. Der Nutzer geht davon aus, dass systemd den verpassten Zeitpunkt beim nächsten Einschalten nachholt, so wie er es von anacron kennt oder schlicht erwartet. Tatsächlich passiert nichts: systemctl list-timers zeigt den nächsten geplanten Zeitpunkt, der wieder in der Nacht liegt, und das Backup läuft wochenlang nie. Weil der Timer selbst aktiv ist und kein Dienst auf failed steht, fällt der Ausfall erst auf, wenn man die Sicherung braucht.
Die „Layer 8“-Wahrheit
Die Handbuchseite systemd.timer(5) macht das Nachholen zu einer ausdrücklichen Option. Persistent= „Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=.“ Die Seite nennt genau den Anwendungsfall: „This is useful to catch up on missed runs of the service when the system was powered down.“ Und sie schließt mit dem Satz, der das Symptom erklärt: „Defaults to false.“ Ohne diese Zeile in der Sektion [Timer] holt systemd also nichts nach. Es ist keine Fehlfunktion, sondern die Voreinstellung.
Zwei Einschränkungen stehen ebenfalls dort. Erstens: „Note that this setting only has an effect on timers configured with OnCalendar=.“ Monotone Timer wie OnBootSec= oder OnUnitActiveSec= rechnen ab dem Systemstart oder ab dem letzten Lauf, für sie ändert die Option nichts, und ein Rechner, der täglich neu startet, beginnt ihren Zeitraum jedes Mal von vorn. Zweitens unterliegt das Nachholen weiterhin der Verzögerung aus RandomizedDelaySec=, sodass der nachgeholte Lauf nicht in derselben Sekunde starten muss. Wer die gespeicherte Marke loswerden will, nutzt laut Seite systemctl clean –what=state auf der Timer-Unit.
Die Erwartung, dass nachgeholt wird, stammt aus einer anderen Welt: anacron wurde genau dafür gebaut, Rechner zu versorgen, die nicht durchlaufen, und viele Nutzer halten jeden Zeitplaner für so gebaut. systemd trennt die beiden Fragen bewusst. Ob ein Termin verpasst werden darf, entscheidet die Unit, nicht der Zeitplaner, und die Antwort lautet so lange ja, bis jemand Persistent=true hineinschreibt. Auf einem Server, der nie ausgeht, merkt man den Unterschied nie. Auf einem Laptop merkt man ihn an dem Tag, an dem man die Sicherung braucht.
Ein Nebeneffekt verdient Erwähnung: Mit Persistent=true läuft der Dienst nach jedem längeren Ausschalten genau einmal nach, nicht für jede verpasste Fälligkeit einzeln. Wer eine Woche im Urlaub war, bekommt beim ersten Start ein Backup, nicht sieben. Für Sicherungen ist das genau richtig; für Aufgaben, die auf jeden Tag einzeln angewiesen sind, etwa das Rotieren von Logdateien mit Datum, muss der Dienst selbst nachsehen, was er versäumt hat.