Ubuntu Manpage: systemd.timer - Timer-Unit-Konfiguration

bezeichnung
übersicht
beschreibung
automatische abhängigkeiten
optionen
siehe auch
übersetzung

BEZEICHNUNG

       systemd.timer - Timer-Unit-Konfiguration

ÜBERSICHT

       Timer.timer

BESCHREIBUNG

Eine Unit-Konfigurationsdatei, deren Namen auf ».timer« endet, kodiert Informationen über einen durch
Systemd gesteuerten und überwachten Timer für die Timer-basierte Aktivierung.

Diese Handbuchseite führt die für diesen Unit-Typ spezifischen Konfigurationsoptionen auf. Siehe
systemd.unit(5) für die gemeinsamen Optionen aller Unit-Konfigurationsdateien. Die gemeinsamen
Konfigurationseinträge werden in den generischen Abschnitten »[Unit]« und »[Install]« konfiguriert. Die
Timer-spezifischen Konfigurationsoptionen werden in dem Abschnitt »[Timer]« konfiguriert.

Für jede Timer-Datei muss eine passende Unit-Datei existieren, welche die zu aktivierende Unit, wenn der
Timer abläuft, beschreibt. Beispiel: Eine Timer-Datei foo.timer aktiviert einen passenden Dienst
foo.service. Die zu aktivierende Unit kann mit Unit= (siehe unten) gesteuert werden.

Beachten Sie, dass die Unit, die der Timer aktivieren soll, nicht neu gestartet wird, wenn sie beim
Ablaufen des Timers bereits aktiv ist, sondern einfach weiterläuft. In diesem Fall gibt es kein Konzept
des Startens neuer Dienste-Instanzen. Daher sind Dienste mit gesetztem RemainAfterExit=yes (die damit
aktiv bleiben, selbst wenn sich der Hauptprozess des Dienstes beendet hat) in der Regel keine guten
Kandidaten für die Aktivierung über wiederholende Timer, da sie nur einmal aktiviert werden und dann für
immer verbleiben. Ziel-Units, die sich standardmäßig nicht von alleine deaktivieren, können wiederholt
durch Timer durch Setzen von StopWhenUnneeded=yes auf sie aktiviert werden. Dies führt dazu, dass eine
Ziel-Unit sofort nach ihrer Aktivierung gestoppt wird, falls sie keine Abhängigkeit von einer anderen
laufenden Unit ist.

AUTOMATISCHE ABHÄNGIGKEITEN

   Implizite Abhängigkeiten
       Die folgenden Abhängigkeiten werden implizit hinzugefügt:

       •   Timer-Units erhalten automatisch eine Abhängigkeit Before= von dem Dienst, den sie aktivieren sollen.

   Standardabhängigkeiten
       Die folgenden Abhängigkeiten werden hinzugefügt, es sei denn, DefaultDependencies=no ist gesetzt:

       •   Timer-Units werden automatisch Abhängigkeiten vom Typ Requires= und After= von sysinit.target, eine
           Abhängigkeit vom Typ Before= von timers.target sowie Conflicts= und Before= von shutdown.target
           haben, um sicherzustellen, dass sie vor dem Herunterfahren des Systems sauber beendet werden. Nur
           Timer-Units, die in der frühen Systemstartphase oder spät beim Herunterfahren beteiligt sind, sollten
           die Option DefaultDependencies= deaktivieren.

       •   Timer-Units mit mindestens einer Anweisung OnCalendar= erlangen ein paar von zusätzlichen
           Abhängigkeiten After= von time-set.target und time-sync.target, um zu vermeiden, dass sie gestartet
           werden, bevor die Systemuhr korrekt gestellt ist. Siehe systemd.special(7) für Details zu diesen zwei
           Zielen.

OPTIONEN

Timer-Unit-Dateien können Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben
sind.

Timer-Unit-Dateien müssen einen Abschnitt [Timer] enthalten, der Informationen über den durch sie
definierten Timer transportiert. Die für den Abschnitt [Timer] von Timer-Units spezifischen Optionen sind
die folgenden:

OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=
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).

OnCalendar=
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.

AccuracySec=
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.

RandomizedDelaySec=
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.

FixedRandomDelay=
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.

DeferReactivation=
Akzeptiert ein logisches Argument. Wenn aktiviert, dann plant der Timer den nächsten Ablauf basierend
auf dem Zeitpunkt, zu dem die Trigger-Unit inaktiv wird, ein, anstatt der letzten Trigger-Zeit. Dies
ist im Fall bei dem die Dienste-Unit länger als das Timer-Intervall benötigt am offensichtlichsten.
Wenn diese Einstellung aktiviert ist, wird der Timer den nächsten Ablauf einplanen, wenn die
Dienste-Unit mit der Ausführung endet und er wird dann warten, bis das näcshte Mal in echter Zeit der
Trigger abläuft. Andernfalls ist das Standardverhalten für die Timer-Unit sofort erneut auszulösen,
sobald die Ausführung des Dienstes abgeschlossen wurde. Dies passiert, da der Timer den nächsten
Ablauf auf die vorherige Trigger-Zeit einplant und da dieses Intervall kürzer als die Laufzeit des
Dienstes ist, liegt dieser Ablaufzeitpunkt in der Vergangenheit und führt zum sofortigen erneuten
Auslösen nach der Beendigung.

Diese Einstellung hat keine Wirkung, falls kein Echtzeit-Timer mit OnCalendar= festgelegt wurde.
Standardmäßig false.

Hinzugefügt in Version 257.

OnClockChange=, OnTimezoneChange=
Diese Optionen akzeptieren logische Argumente. Falls true, 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.

Unit=
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.

Persistent=
Akzeptiert ein logisches Argument. Falls true, 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.

WakeSystem=
Akzeptiert ein logisches Argument. Falls true, 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 false, wird eine monotone Uhr verwandt, die während der
Systemsuspendierung pausiert ((CLOCK_MONOTONIC), falls true, 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.

RemainAfterElapse=
Akzeptiert ein logisches Argument. Falls true, 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 false, 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.

Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) für weitere Einstellungen.

SIEHE AUCH

       Für die ausgelösten Units werden Umgebungsvariablen mit Details über den Trigger gesetzt. Siehe den
       Abschnitt »Vom Diensteverwalter gesetzte oder ausgebreitete Umgebungsvariablen« in systemd.exec(5) für
       weitere Details.

       systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), systemd.time(7), systemd.directives(7),
       systemd-system.conf(5), prctl(2)

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.