Definiert monotone Timer relativ zu verschiedenen Startpunkten:

Tabelle 1. Einstellungen und ihre Startpunkte

Einstellung	Bedeutung
OnActiveSec=	Definiert einen Timer relativ zu dem Moment, zu dem die Timer-Unit selbst aktiviert wurde.
OnBootSec=	Definiert einen Timer relativ zum Zeitpunkt des Systemstarts. Für die Systemverwalterinstanz wird dies in Containern auf OnStartupSec= abgebildet, wodurch beide äquivalent werden.
OnStartupSec=	Definiert einen Timer relativ zum erstmaligen Start des Diensteverwalters. Für System-Timer-Units ist dies sehr ähnlich zu OnBootSec=, da der Systemdiensteverwalter im Allgemeinen sehr früh im Systemstartprozess gestartet wird. Es ist hauptsächlich nützlich, wenn dies in Units konfiguriert wird, die im benutzerbezogenen Diensteverwalter laufen, da der Benutzerdiensteverwalter im Allgemeinen nur beim erstmaligen Anmelden und nicht bereits während des Systemstarts gestartet wird.
OnUnitActiveSec=	Definiert einen Timer relativ zu dem Zeitpunkt, zu dem die Unit, die der Timer aktiviert, letztmalig aktiviert wurde.
OnUnitInactiveSec=	Definiert einen Timer relativ zu dem Zeitpunkt, zu dem die Unit, die der Timer aktiviert, letztmalig deaktiviert wurde.

Mehrere Anweisungen vom gleichen oder von verschiedenen Typen können kombiniert werden. In diesem Fall werden die Timer-Units auslösen, wannimmer einer der festgelegten Timer-Ausdrücke abläuft. Beispielsweise ist es durch Kombination von OnBootSec= und OnUnitActiveSec= möglich, einen Timer zu definieren, der in regelmäßigen Abständen abläuft und jedes Mal einen bestimmten Dienst aktiviert. Desweiteren können sowohl monotone Zeit- als auch kalendarische OnCalendar=-Ausdrücke in der gleichen Timer-Unit kombiniert werden.

Die Argumente für die Anweisung sind in Sekunden konfigurierte Zeitspannen. Beispiel: »OnBootSec=50« bedeutet 50 s nach Systemstart. Das Argument kann auch Zeiteinheiten enthalten. Beispiel: »OnBootSec=5h 30min« bedeutet 5 Stunden und 30 Minuten nach Systemstart. Für Details über die Syntax von Zeitspannen, siehe systemd.time(7).

Falls ein mit OnBootSec= oder OnStartupSec= konfigurierter Timer bereits in der Vergangenheit liegt, wenn die Timer-Unit aktiviert wird, wird er sofort ablaufen und die konfigurierte Unit wird gestartet. Dies ist bei Timern, die in anderen Anweisungen definiert sind, nicht der Fall.

Es gibt monotone Timer, die von der Standarduhrzeit und Zeitzonen unabhängig sind. Falls der Computer vorübergehend suspendiert wird, pausiert auch die monotone Uhr. Beachten Sie, dass eine andere monotone Uhr ausgewählt wird, die während der Systemsuspendierung weiter fortschreitet, falls WakeSystem= verwandt wird, und die daher als Auslöser zum Wiederaufnehmen des Systems verwandt werden kann.

Falls einer dieser Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Timer zurückgesetzt (sowohl monotoner Timer als auch OnCalendar=-Timer, siehe unten) und alle vorhergehenden Zuweisungen haben keine Auswirkung.

Beachten Sie, dass Timer nicht notwendigerweise zu dem exakten Zeitpunkt, der mit diesen Einstellungen konfiguriert ist, auslaufen. Sie unterliegen der Einstellung AccuracySec= (siehe weiter unten).

Definiert Echtzeit- (d.h. Wanduhr-)Timer mit Kalenderereignisausdrücken. Siehe systemd.time(7) für weitere Informationen über die Syntax von Kalenderereignisausdrücken. Abgesehen davon ist die Semantik ähnlich zu der von OnActiveSec= und verwandten Einstellungen.

Beachten Sie, dass Timer nicht notwendigerweise zu dem exakten Zeitpunkt, der mit dieser Einstellung konfiguriert ist, auslaufen. Sie unterliegen der Einstellung AccuracySec= (siehe weiter unten).

Kann mehr als einmal angegeben werden, wodurch die Timer-Unit ausgelöst wird, wannimmer einer der festgelegten Ausdrücke abläuft. Desweiteren können Kalender-Timer und monotone Timer (siehe oben) in der gleichen Timer-Unit kombiniert werden.

Falls einer dieser Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Timer zurückgesetzt (sowohl OnCalendar=-Timer als auch monotone Timer, siehe oben) und alle vorhergehenden Zuweisungen haben keine Auswirkung.

Beachten Sie, dass Kalender-Timer zu unerwarteten Zeitpunkten ausgelöst werden können, wenn die Echtzeituhr des Systems nicht korrekt gesetzt ist. Insbesondere auf Systemen, denen eine Batterie-gestützte Echtzeituhr (RTC) fehlt, könnte es ratsam sein, systemd-time-wait-sync.service zu aktivieren, um sicherzustellen, dass die Uhr mit einer Netzwerkzeit angepasst wird, bevor das Timer-Ereignis eingerichtet wird. Timer-Units mit mindestens einem Ausdruck OnCalendar= werden automatisch nach time-sync.target sortiert, wobei systemd-time-wait-sync.service davor einsortiert ist.

Wenn ein System temporär in den Schlafzustand gelegt wird (d.h. Systemsupendierung oder Ruhezustand), pausiert die Echtzeituhr nicht. Wenn ein Kalender-Timer abläuft, während das System schläft, wird nicht sofort darauf reagiert, aber sobald das System später wieder aufgenommen wird, wird es das nachholen und alle Timer verarbeiten, die während des Schlafzustandes ausgelöst hatten. Beachten Sie, dass der Timer nur zu einer einzelnen Dienste-Aktivierung führen wird, selbst falls ein Kalender-Timer mehrfach ablief, während das System im Schlafzustand war. Falls (das nachfolgend beschriebene) WakeSystem= aktiviert ist, führt das Ablaufen eines Timer-Ereignisses während das Ssytem suspendiert ist zu dem Aufwachen (unter der Bedingung, dass die Hardware des Systems das Zeit-ausgelöste Aufwachen unterstützt).

Hinzugefügt in Version 197.

Gibt die Genauigkeit an, mit der der Timer ablaufen soll. Standardmäßig 1min. Der Timer wird so eingeplant, dass er innerhalb eines Zeitfensters abläuft, das mit der in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= oder OnUnitInactiveSec= festgelegten Zeit beginnt und zu der mit AccuracySec= konfigurierten Zeit später endet. Innerhalb dieses Zeitfensters wird die Ablaufzeit auf eine Rechner-spezifische, zufällige aber stabile Position gelegt, die unter allen lokalen Timer-Units synchronisiert ist. Dies erfolgt, um den Stromverbrauch zu optimieren, um unnötiges Aufwachen der CPU zu vermeiden. Um die größte Genauigkeit zu erhalten, setzen Sie diese Option auf 1us. Beachten Sie, dass der Timer weiterhin dem mit der Einstellung TimerSlackNSec= von systemd-system.conf(5) konfigurierten Timer-Spielraum unterliegt. Siehe prctl(2) für Details. Um den Stromverbrauch zu optimieren, wählen Sie diesen Wert so hoch wie möglich und so niedrig wie notwendig.

Bechten Sie, dass diese Einstellung primär eine Energiesparoption ist, die das Vereinigen des Aufwachens von CPUs ermöglicht. Sie sollte nicht mit RandomizedDelaySec= (siehe unten) durcheinandergebracht werden, die einen zufälligen Wert zu dem Zeitpunkt hinzufügt, an dem der Timer das nächste Mal ablaufen soll und dessen Zweck das Gegenteil ist: um das Ablaufen von Timer-Ereignissen über eine längere Periode zu strecken, um Lastspitzen zu reduzieren. Lesen Sie weiter unten weitere Details und Erklärungen, wie beide Einstellungen zusammenwirken.

Hinzugefügt in Version 209.

Verzögert den Timer um eine zufällig ausgewählte, gleichmäßig verteilte Zeitspanne zwischen 0 und dem angegebenen Wert. Standardmäßig 0, wodurch angezeigt wird, dass keine zufällige Verzögerung angewandt werden soll. Jede Timer-Unit wird diese Verzögerung zufällig vor jeder Wiederholung bestimmen und die Verzögerung wird einfach zusätzlich zu der nächsten ablaufenden Zeit hinzugefügt, außer dies wird mit dem nachfolgend beschriebenen FixedRandomDelay= verändert.

Diese Einstellung ist nützlich, um das Absetzen von ähnlich konfigurierten Timer-Ereignissen über ein Zeitintervall auszudehnen, um zu verhindern, dass sie alle gleichzeitig auslösen und damit möglicherweise zu einer Ressourcenüberlastung führen.

Beachten Sie die Beziehung zu AccuracySec= (weiter oben): Letzteres erlaubt dem Diensteverwalter, Timer-Ereignisse innerhalb einer bestimmten Zeitspanne zusammenzuführen, um das Aufwachen zu minimieren während diese Einstellung das Gegenteil macht: sie verteilt Timer-Ereignisse über ein Intervall, damit gleichzeitiges Feuern unwahrscheinlich wird. Falls RandomizedDelaySec= und AccuracySec= zusammen verwandt werden, wird zuerst die zufällige Verzögerung addiert und dann wird das Ergebnis möglicherweise weiter verschoben, um es mit anderen, auf dem System stattfindenden Timer-Ereignissen zusammenzuführen. Wie oben erwähnt, ist die Vorgabe für AccuracySec= 1 Minute und für RandomizedDelaySec= 0, wodurch das Zusammenführen von Timer-Ereignissen ermutigt wird. Um Timer-Ereignisse optimal über eine bestimmte Zeitspanne zu verteilen, setzen Sie AccuracySec=1us und RandomizedDelaySec= auf einen höheren Wert.

Hinzugefügt in Version 229.

Akzeptiert ein logisches Argument. Wenn aktiviert, wird der für RandomizedDelaySec= festgelegte zufällige Versatz bei jedem Auslösen des gleichen Timers verwandt. Für eine bestimmte Timer-Unit hängt der Versatz von der Maschinenkennung, dem Benutzerkennzeichner und dem Namen des Timers ab, was bedeutet, dass dies über Neustarts des Verwalters hinweg stabil ist. Damit wird tatsächlich ein fester Versatz für einen individuellen Timer erstellt und die Schwankungen beim Auslösen des Timers reduziert, aber dennoch das gleichzeitige Auslösen mit anderen, ähnlich konfigurierten Timern vermieden.

Diese Einstellung hat keine Wirkung, falls RandomizedDelaySec= auf 0 gesetzt ist. Standardmäßig false.

Hinzugefügt in Version 247.

Diese Optionen akzeptieren logische Argumente. Falls wahr, wird die Dienste-Unit ausgelöst, wenn die Systemuhr (CLOCK_REALTIME) relativ zu der monotonen Uhr (CLOCK_MONOTONIC) springt oder wenn die lokale Systemzeitzone verändert wird. Diese Optionen können alleine oder in Kombination mit anderen Timer-Ausdrücken (siehe oben) innerhalb der gleichen Timer-Unit verwandt werden. Diese Optionen sind standardmäßig false.

Hinzugefügt in Version 242.

Die Unit, die beim Ablaufen des Timers aktiviert werden soll. Das Argument ist ein Unit-Name, dessen Endung nicht ».timer« ist. Falls dieser Wert nicht angegeben ist, ist die Vorgabe ein Dienst, der den gleichen Namen (bis auf die Endung) wie die Timer-Unit hat. (Siehe oben.) Es wird empfohlen, dass der Unit-Name, der aktiviert wird, und der Unit-Name der Timer-Unit bis auf die Endung identisch sind.

Akzeptiert ein logisches Argument. Falls wahr, wird der Zeitpunkt, zu dem die Dienste-Unit das letzte Mal ausgelöst wurde, auf Platte gespeichert. Wenn der Timer aktiviert wird, wird die Dienste-Unit sofort ausgelöst, falls sie mindestens einmal in der Zeit, zu der der Timer inaktiv war, ausgelöst worden wäre. Dieses Auslösen unterliegt dennoch der durch RandomizedDelaySec= auferlegten Verzögerung. Dies ist nützlich, um verpasste Läufe, als die Maschine ausgeschaltet gewesen ist, nachzuholen. Beachten Sie, dass diese Einstellung nur für mit OnCalendar= konfigurierte Timer Wirkung entfaltet. Standardmäßig false.

Verwenden Sie systemctl clean --what=state … auf der Timer-Unit, um den durch diese Option verwalteten Zeitstempel auf der Platte zu entfernen. Verwenden Sie diesen Befehl insbesondere bevor Sie eine Timer-Unit deinstallieren. Siehe systemctl(1) für Details.

Hinzugefügt in Version 212.

Akzeptiert ein logisches Argument. Falls wahr, wird ein ablaufender Timer dazu führen, dass das System aus dem Suspend aufwacht, falls das System suspendiert war und das System dieses unterstützt. Beachten Sie, dass dies nur sicherstellt, dass das System zu einer geeigneten Zeit aufwacht. Die Option wird nicht dafür sorgen, dass das System nach Abschluss der zu erledigenden Arbeiten wieder suspendiert wird. Standardmäßig false.

Beachten Sie, dass diese Funktionalität Privilegien benötigt und daher im Allgemeinen nur im Systemdiensteverwalter verfügbar ist.

Beachten Sie, dass das Verhalten monotoner Uhrzeitgeber (wie mit OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec= konfiguriert, siehe oben) abhängig von dieser Option geändert wird. Falls falsch, wird eine monotone Uhr verwandt, die während der Systemsuspendierung pausiert ((CLOCK_MONOTONIC), falls wahr, wird eine andere monotone Uhr verwandt, die während der Systemsupendierung weiterläuft (CLOCK_BOOTTIME), siehe clock_getres(2) für Details.

Hinzugefügt in Version 212.

Akzeptiert ein logisches Argument. Falls wahr, wird ein Timer geladen bleiben und sein Zustand kann weiter abgefragt werden, selbst nachdem er abgelaufen ist und seine zugehörige Unit (wie mit Unit= konfiguriert, siehe oben) wieder deaktiviert wurde. Falls falsch, wird ein abgelaufener Timer, der nicht mehr ablaufen kann, entladen, sobald seine zugehörige Unit wieder deaktiviert wurde. Insbesondere für flüchtige Timer-Units ist es besonders nützlich, dies abzuschalten. Beachten Sie, dass diese Einstellung Auswirkungen hat, wenn eine Timer-Unit wiederholt gestartet wird: Falls RemainAfterElapse= eingeschaltet ist, hat das erneute Starten des Timers keine Auswirkung. Falls allerdings RemainAfterElapse= ausgeschaltet ist und die Timer-Unit bereits wieder entladen wurde, kann sie erneut gestartet und daher mehrfach ausgelöst werden. Standardmäßig true.

Hinzugefügt in Version 229.