SYSTEMD.TIMER(5)

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, außer dies wird mit dem nachfolgend beschriebenen FixedRandomDelay= verändert. Die Verzögerung wird einfach zusätzlich zu der nächsten ablaufenden Zeit oder zu der Hochfahrzeit des Diensteverwalters hinzugefügt, welche davon später eintritt.

    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 auf dem lokalen System 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 die für RandomizedDelaySec= festgelegte zufällige Verzögerung deterministisch bestimmt und bleibt zwischen allen Auslösen des gleichen Timers stabil, selbst wenn der Verwalter neu gestartet wird. Die Verzögerung wird aus der Maschinenkennung, dem Benutzerkennzeichner des Verwalters und dem Namen des Timers abgeleitet. Damit wird tatsächlich ein eindeutiger fester Versatz für jeden Timer erstellt und die Schwankungen beim Auslösen eines individuellen Timers reduziert, aber dennoch das gleichzeitige Auslösen mit anderen, ähnlich konfigurierten Timern vermieden.

    Diese Einstellung ist nur wirksam, falls RandomizedDelaySec= nicht auf 0 gesetzt ist. Standardmäßig false.

    Hinzugefügt in Version 247.

RandomizedOffsetSec=
    Versetzt den Timer um eine stabile, zufällig ausgewählte, gleichmäßig verteilte Zeitspanne zwischen 0 und dem angegebenen Wert. Standardmäßig 0, wodurch angezeigt wird, dass kein solcher Versatz angewandt werden soll. Der Versatz wird deterministisch ausgewählt und auf die gleiche Art wie FixedRandomDelay= abgeleitet, siehe oben. Der Versatz wird zu der nächsten ermittelten abgelaufenen Zeit hinzugefügt. Diese Einstellung wird nur bei Timern wirksam, die mit OnCalendar= konfiguriert sind, und kann mit RandomizedDelaySec= kombiniert werden.

    Ähnlich wie RandomizedDelaySec= ist diese Einstellung dazu gedacht, die Timer-Ereignisse zu verteilen, damit sie nicht alle gleichzeitig auslösen. Allerdings ist diese Einstellung am nützlichsten, um Ressourcen-Verstopfung auf fernen Diensten von einer Gruppe an ähnlich konfigurierten Clients zu vermeiden. Anders als bei RandomizedDelaySec= wendet diese Einstellung ihren Versatz unabhängig von der Startdauer des Verwalters an. Dies erhält die Periodizität von konfigurierten OnCalendar=-Ereignissen über Neustarts des Verwalters hinweg.

    Betreiben Sie beispielsweise einen Datensicherungsdienst und haben eine Gruppe von Laptops, die wöchentlich eine Datensicherung durchführen sollen. Um die Last auf dem Datensicherungsdienst zu verteilen, soll jeder Laptop zufällig einen Wochentag heraussuchen, um seine Datensicherungen hochzuladen. Dies könnte mittels einer Einstellung von OnCalendar= auf »weekly« und anschließender Konfiguration einer RandomizedDelaySec= auf »5 days« mit aktiviertem FixedRandomDelay= erreicht werden. Wählt ein Laptop zufällig eine Verzögerung von 4 Tagen und wird dieser Laptop häufiger als dies neu gestartet, dann wird der Timer niemals auslösen: nach jedem Neustart wird die 4-Tage-Verzögerung neu gestartet und wird vor dem Zeitpunkt des nächsten Herunterfahrens nicht abgelaufen sein. Stattdessen sollten Sie RandomizedOffsetSec= verwenden, das den konfigurierten wöchentlichen Rhythmus beibehält, selbst über Neustarts hinweg.

    Hinzugefügt in Version 258.

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 ist nur wirksam, wenn ein 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.