SYSTEMD.TIMER(5) systemd.timer SYSTEMD.TIMER(5) BEZEICHNUNG systemd.timer - Timer-Unit-Konfiguration UBERSICHT Timer.timer BESCHREIBUNG Eine Unit-Konfigurationsdatei, deren Namen auf >>.timer<< endet, kodiert Informationen uber einen durch Systemd gesteuerten und uberwachten Timer fur die Timer-basierte Aktivierung. Diese Handbuchseite fuhrt die fur diesen Unit-Typ spezifischen Konfigurationsoptionen auf. Siehe systemd.unit(5) fur die gemeinsamen Optionen aller Unit-Konfigurationsdateien. Die gemeinsamen Konfigurationseintrage werden in den generischen Abschnitten >>[Unit]<< und >>[Install]<< konfiguriert. Die Timer-spezifischen Konfigurationsoptionen werden in dem Abschnitt >>[Timer]<< konfiguriert. Fur jede Timer-Datei muss eine passende Unit-Datei existieren, welche die zu aktivierende Unit, wenn der Timer ablauft, 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 weiterlauft. 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 fur die Aktivierung uber wiederholende Timer, da sie nur einmal aktiviert werden und dann fur immer verbleiben. Ziel-Units, die sich standardmassig nicht von alleine deaktivieren, konnen wiederholt durch Timer durch Setzen von StopWhenUnneeded=yes auf sie aktiviert werden. Dies fuhrt dazu, dass eine Ziel-Unit sofort nach ihrer Aktivierung gestoppt wird, falls sie keine Abhangigkeit von einer anderen laufenden Unit ist. AUTOMATISCHE ABHANGIGKEITEN Implizite Abhangigkeiten Die folgenden Abhangigkeiten werden implizit hinzugefugt: o Timer-Units erhalten automatisch eine Abhangigkeit Before= von dem Dienst, den sie aktivieren sollen. Standardabhangigkeiten Die folgenden Abhangigkeiten werden hinzugefugt, es sei denn, DefaultDependencies=no ist gesetzt: o Timer-Units werden automatisch Abhangigkeiten vom Typ Requires= und After= von sysinit.target, eine Abhangigkeit 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 fruhen Systemstartphase oder spat beim Herunterfahren beteiligt sind, sollten die Option DefaultDependencies= deaktivieren. o Timer-Units mit mindestens einer Anweisung OnCalendar= erlangen ein paar von zusatzlichen Abhangigkeiten 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) fur Details zu diesen zwei Zielen. OPTIONEN Timer-Unit-Dateien konnen Abschnitte [Unit] und [Install] enthalten, die in systemd.unit(5) beschrieben sind. Timer-Unit-Dateien mussen einen Abschnitt [Timer] enthalten, der Informationen uber den durch sie definierten Timer transportiert. Die fur 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. Fur die | | | Systemverwalterinstanz | | | wird dies in Containern | | | auf OnStartupSec= | | | abgebildet, wodurch beide | | | aquivalent werden. | +-------------------+----------------------------+ |OnStartupSec= | Definiert einen Timer | | | relativ zum erstmaligen | | | Start des | | | Diensteverwalters. Fur | | | System-Timer-Units ist | | | dies sehr ahnlich zu | | | OnBootSec=, da der | | | Systemdiensteverwalter im | | | Allgemeinen sehr fruh im | | | Systemstartprozess | | | gestartet wird. Es ist | | | hauptsachlich nutzlich, | | | wenn dies in Units | | | konfiguriert wird, die im | | | benutzerbezogenen | | | Diensteverwalter laufen, | | | da der | | | Benutzerdiensteverwalter | | | im Allgemeinen nur beim | | | erstmaligen Anmelden und | | | nicht bereits wahrend 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 konnen kombiniert werden. In diesem Fall werden die Timer-Units auslosen, wannimmer einer der festgelegten Timer-Ausdrucke ablauft. Beispielsweise ist es durch Kombination von OnBootSec= und OnUnitActiveSec= moglich, einen Timer zu definieren, der in regelmassigen Abstanden ablauft und jedes Mal einen bestimmten Dienst aktiviert. Desweiteren konnen sowohl monotone Zeit- als auch kalendarische OnCalendar=-Ausdrucke in der gleichen Timer-Unit kombiniert werden. Die Argumente fur 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. Fur Details uber 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 unabhangig sind. Falls der Computer vorubergehend suspendiert wird, pausiert auch die monotone Uhr. Beachten Sie, dass eine andere monotone Uhr ausgewahlt wird, die wahrend der Systemsuspendierung weiter fortschreitet, falls WakeSystem= verwandt wird, und die daher als Ausloser zum Wiederaufnehmen des Systems verwandt werden kann. Falls einer dieser Optionen die leere Zeichenkette zugewiesen wird, wird die Liste der Timer zuruckgesetzt (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 Kalenderereignisausdrucken. Siehe systemd.time(7) fur weitere Informationen uber die Syntax von Kalenderereignisausdrucken. Abgesehen davon ist die Semantik ahnlich 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 ausgelost wird, wannimmer einer der festgelegten Ausdrucke ablauft. Desweiteren konnen 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 zuruckgesetzt (sowohl OnCalendar=-Timer als auch monotone Timer, siehe oben) und alle vorhergehenden Zuweisungen haben keine Auswirkung. Beachten Sie, dass Kalender-Timer zu unerwarteten Zeitpunkten ausgelost werden konnen, wenn die Echtzeituhr des Systems nicht korrekt gesetzt ist. Insbesondere auf Systemen, denen eine Batterie-gestutzte Echtzeituhr (RTC) fehlt, konnte 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 temporar in den Schlafzustand gelegt wird (d.h. Systemsupendierung oder Ruhezustand), pausiert die Echtzeituhr nicht. Wenn ein Kalender-Timer ablauft, wahrend das System schlaft, wird nicht sofort darauf reagiert, aber sobald das System spater wieder aufgenommen wird, wird es das nachholen und alle Timer verarbeiten, die wahrend des Schlafzustandes ausgelost hatten. Beachten Sie, dass der Timer nur zu einer einzelnen Dienste-Aktivierung fuhren wird, selbst falls ein Kalender-Timer mehrfach ablief, wahrend das System im Schlafzustand war. Falls (das nachfolgend beschriebene) WakeSystem= aktiviert ist, fuhrt das Ablaufen eines Timer-Ereignisses wahrend das Ssytem suspendiert ist zu dem Aufwachen (unter der Bedingung, dass die Hardware des Systems das Zeit-ausgeloste Aufwachen unterstutzt). Hinzugefugt in Version 197. AccuracySec= Gibt die Genauigkeit an, mit der der Timer ablaufen soll. Standardmassig 1min. Der Timer wird so eingeplant, dass er innerhalb eines Zeitfensters ablauft, das mit der in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= oder OnUnitInactiveSec= festgelegten Zeit beginnt und zu der mit AccuracySec= konfigurierten Zeit spater endet. Innerhalb dieses Zeitfensters wird die Ablaufzeit auf eine Rechner-spezifische, zufallige aber stabile Position gelegt, die unter allen lokalen Timer-Units synchronisiert ist. Dies erfolgt, um den Stromverbrauch zu optimieren, um unnotiges Aufwachen der CPU zu vermeiden. Um die grosste 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) fur Details. Um den Stromverbrauch zu optimieren, wahlen Sie diesen Wert so hoch wie moglich und so niedrig wie notwendig. Bechten Sie, dass diese Einstellung primar eine Energiesparoption ist, die das Vereinigen des Aufwachens von CPUs ermoglicht. Sie sollte nicht mit RandomizedDelaySec= (siehe unten) durcheinandergebracht werden, die einen zufalligen Wert zu dem Zeitpunkt hinzufugt, an dem der Timer das nachste Mal ablaufen soll und dessen Zweck das Gegenteil ist: um das Ablaufen von Timer-Ereignissen uber eine langere Periode zu strecken, um Lastspitzen zu reduzieren. Lesen Sie weiter unten weitere Details und Erklarungen, wie beide Einstellungen zusammenwirken. Hinzugefugt in Version 209. RandomizedDelaySec= Verzogert den Timer um eine zufallig ausgewahlte, gleichmassig verteilte Zeitspanne zwischen 0 und dem angegebenen Wert. Standardmassig 0, wodurch angezeigt wird, dass keine zufallige Verzogerung angewandt werden soll. Jede Timer-Unit wird diese Verzogerung zufallig vor jeder Wiederholung bestimmen und die Verzogerung wird einfach zusatzlich zu der nachsten ablaufenden Zeit hinzugefugt, ausser dies wird mit dem nachfolgend beschriebenen FixedRandomDelay= verandert. Diese Einstellung ist nutzlich, um das Absetzen von ahnlich konfigurierten Timer-Ereignissen uber ein Zeitintervall auszudehnen, um zu verhindern, dass sie alle gleichzeitig auslosen und damit moglicherweise zu einer Ressourcenuberlastung fuhren. Beachten Sie die Beziehung zu AccuracySec= (weiter oben): Letzteres erlaubt dem Diensteverwalter, Timer-Ereignisse innerhalb einer bestimmten Zeitspanne zusammenzufuhren, um das Aufwachen zu minimieren wahrend diese Einstellung das Gegenteil macht: sie verteilt Timer-Ereignisse uber ein Intervall, damit gleichzeitiges Feuern unwahrscheinlich wird. Falls RandomizedDelaySec= und AccuracySec= zusammen verwandt werden, wird zuerst die zufallige Verzogerung addiert und dann wird das Ergebnis moglicherweise weiter verschoben, um es mit anderen, auf dem System stattfindenden Timer-Ereignissen zusammenzufuhren. Wie oben erwahnt, ist die Vorgabe fur AccuracySec= 1 Minute und fur RandomizedDelaySec= 0, wodurch das Zusammenfuhren von Timer-Ereignissen ermutigt wird. Um Timer-Ereignisse optimal uber eine bestimmte Zeitspanne zu verteilen, setzen Sie AccuracySec=1us und RandomizedDelaySec= auf einen hoheren Wert. Hinzugefugt in Version 229. FixedRandomDelay= Akzeptiert ein logisches Argument. Wenn aktiviert, wird der fur RandomizedDelaySec= festgelegte zufallige Versatz bei jedem Auslosen des gleichen Timers verwandt. Fur eine bestimmte Timer-Unit hangt der Versatz von der Maschinenkennung, dem Benutzerkennzeichner und dem Namen des Timers ab, was bedeutet, dass dies uber Neustarts des Verwalters hinweg stabil ist. Damit wird tatsachlich ein fester Versatz fur einen individuellen Timer erstellt und die Schwankungen beim Auslosen des Timers reduziert, aber dennoch das gleichzeitige Auslosen mit anderen, ahnlich konfigurierten Timern vermieden. Diese Einstellung hat keine Wirkung, falls RandomizedDelaySec= auf 0 gesetzt ist. Standardmassig false. Hinzugefugt in Version 247. OnClockChange=, OnTimezoneChange= Diese Optionen akzeptieren logische Argumente. Falls wahr, wird die Dienste-Unit ausgelost, wenn die Systemuhr (CLOCK_REALTIME) relativ zu der monotonen Uhr (CLOCK_MONOTONIC) springt oder wenn die lokale Systemzeitzone verandert wird. Diese Optionen konnen alleine oder in Kombination mit anderen Timer-Ausdrucken (siehe oben) innerhalb der gleichen Timer-Unit verwandt werden. Diese Optionen sind standardmassig false. Hinzugefugt 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 ausgelost wurde, auf Platte gespeichert. Wenn der Timer aktiviert wird, wird die Dienste-Unit sofort ausgelost, falls sie mindestens einmal in der Zeit, zu der der Timer inaktiv war, ausgelost worden ware. Dieses Auslosen unterliegt dennoch der durch RandomizedDelaySec= auferlegten Verzogerung. Dies ist nutzlich, um verpasste Laufe, als die Maschine ausgeschaltet gewesen ist, nachzuholen. Beachten Sie, dass diese Einstellung nur fur mit OnCalendar= konfigurierte Timer Wirkung entfaltet. Standardmassig 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) fur Details. Hinzugefugt in Version 212. WakeSystem= Akzeptiert ein logisches Argument. Falls wahr, wird ein ablaufender Timer dazu fuhren, dass das System aus dem Suspend aufwacht, falls das System suspendiert war und das System dieses unterstutzt. Beachten Sie, dass dies nur sicherstellt, dass das System zu einer geeigneten Zeit aufwacht. Die Option wird nicht dafur sorgen, dass das System nach Abschluss der zu erledigenden Arbeiten wieder suspendiert wird. Standardmassig false. Beachten Sie, dass diese Funktionalitat Privilegien benotigt und daher im Allgemeinen nur im Systemdiensteverwalter verfugbar ist. Beachten Sie, dass das Verhalten monotoner Uhrzeitgeber (wie mit OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec= konfiguriert, siehe oben) abhangig von dieser Option geandert wird. Falls falsch, wird eine monotone Uhr verwandt, die wahrend der Systemsuspendierung pausiert ((CLOCK_MONOTONIC), falls wahr, wird eine andere monotone Uhr verwandt, die wahrend der Systemsupendierung weiterlauft (CLOCK_BOOTTIME), siehe clock_getres(2) fur Details. Hinzugefugt 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 zugehorige Unit (wie mit Unit= konfiguriert, siehe oben) wieder deaktiviert wurde. Falls falsch, wird ein abgelaufener Timer, der nicht mehr ablaufen kann, entladen, sobald seine zugehorige Unit wieder deaktiviert wurde. Insbesondere fur fluchtige Timer-Units ist es besonders nutzlich, 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 ausgelost werden. Standardmassig true. Hinzugefugt in Version 229. Lesen Sie systemd.unit(5), systemd.exec(5) und systemd.kill(5) fur weitere Einstellungen. SIEHE AUCH Fur die ausgelosten Units werden Umgebungsvariablen mit Details uber den Trigger gesetzt. Siehe den Abschnitt >>Vom Diensteverwalter gesetzte oder ausgebreitete Umgebungsvariablen<< in systemd.exec(5) fur weitere Details. systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), systemd.time(7), systemd.directives(7), systemd-system.conf(5), prctl(2) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.TIMER(5)