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

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.

OnClockChange=, OnTimezoneChange=
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.

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

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

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

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⟩.