Systemd/Timers: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Tuxnix (Diskussion | Beiträge)
1.687 Bearbeitungen
Die Seite wurde neu angelegt: „{{inuse|~~~}} {{Lowercase title}} Category:Daemons and system services Category:Boot process de:Systemd/Timers fr:Systemd/cron ja:Systemd/タ…“
 
Jewox (Diskussion | Beiträge)
302 Bearbeitungen
 
(38 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}
{{righttoc}}
{{Lowercase title}}
Timer bieten die Möglichkeit Aufgaben zeitlich zu steuern. Die Timer-Unit besteht aus einer {{ic|.timer}} Datei die eine {{ic|.service}} Datei ansteuert.
[[Category:Daemons and system services]]
Timer unterstehen [[systemd]] und müssen mit dem systemctl Befehl aktiviert werden. Eine Alternative hierzu bietet [[cron]].
[[Category:Boot process]]
[[de:Systemd/Timers]]
[[fr:Systemd/cron]]
[[ja:Systemd/タイマー]]
[[ru:Systemd/Timers]]
[[zh-hans:Systemd/Timers]]
{{Related articles start}}
{{Related|systemd}}
{{Related|systemd/User}}
{{Related|systemd FAQ}}
{{Related|cron}}
{{Related articles end}}
Timer bieten die Möglichkeit Aufgaben zeitgerecht zu steuern. Sie bestehen aus einer {{ic|.timer}} und einer {{ic|.service}} Datei.
Der Timer Dienst wird von [[systemd]] gesteuert und müssen mit einem systemctl Befehl aktiviert werden. Alternativen sind [[cron]] und [[anacron]].


==Hinweis==
== Beispiel ==


Dies ist mein erster Archwicki Artikel. Er ist gerade erst im entstehen
=== Die {{ic|.timer}} Datei ===
Der englische Archwikiartikel dient lediglich als Vorlage.
<nowiki># Datei /etc/systemd/system/beispiel.timer


==Beispiel==
[Unit]
Description=Beispielaktion nach 1St 30Min


==={{ic|.timer}} Datei===
[Timer]
OnBootSec=1h 30m


==={{ic|.service}} Datei===
[Install]
WantedBy=basic.target</nowiki>


===Aktivierung===
=== Die {{ic|.service}} Datei ===
<nowiki># Datei /etc/systemd/system/beispiel.service


== Timer units ==
[Unit]
Timers are like other [[systemd#Writing unit files|unit configuration files]] and are loaded from the same paths but include a {{ic|[Timer]}} section.  The {{ic|[Timer]}} section defines when and how the timer activates. Timers are defined as one of two types:
Description=Beispiel Service


* '''Monotonic timers''' activate after a time span relative to a varying starting point. There are number of different monotonic timers but all have the form of: {{ic|1=On''Type''Sec=}}.  {{ic|OnBootSec}} and {{ic|OnActiveSec}} are common monotonic timers.
[Service]
* '''Realtime timers''' (a.k.a. wallclock timers) activate on a calendar event (like cronjobs). The option {{ic|1=OnCalendar=}} is used to define them.
ExecStart=/home/<user>/beispiel.sh</nowiki>


For a full explanation of timer options, see the {{man|5|systemd.timer}}. The argument syntax for calendar events and time spans is defined in {{man|7|systemd.time}}.
Dieses Beispiel stellt eine Minimalvariante der Dateien dar. Weiteres siehe [[Systemd/Timers#Optionen]].


== Service unit ==
Als [Service] kann ein Befehl oder ein ausführbares Script genutzt werden.


For each {{ic|.timer}} file, a matching {{ic|.service}} file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}).  The {{ic|.timer}} file activates and controls the {{ic|.service}} file.  The {{ic|.service}} does not require an {{ic|[Install]}} section as it is the ''timer'' units that are enabled.  If necessary, it is possible to control a differently-named unit using the {{ic|1=Unit=}} option in the timer's {{ic|[Timer]}} section.
Service- und Timerdatei werden mit root Rechten in /etc/systemd/system/ abgelegt und müssen vor dem . (Punkt) den gleichen Namen tragen.


== Management ==
=== De-/Aktivierung ===
systemctl enable --now beispiel.timer
(Bei der ersten Initialisierung legt das System automatisch einen symlink /etc/systemd/system/basic.target.wants/ → /etc/systemd/system/ der {{ic|.timer}} Datei an.)


To use a ''timer'' unit [[enable]] and [[start]] it like any other unit (remember to add the {{ic|.timer}} suffix).  To view all started timers, run:
Mit ''enable --now'' startet der Timer unverzüglich und permanent, sodass er auch nach einem Neustart aktiv ist.


{{hc|$ systemctl list-timers|
Ohne ''--now'' werden ''enable oder disable'' erst nach einem reboot wirksam.
NEXT                          LEFT        LAST                          PASSED    UNIT                        ACTIVATES
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST  15h left    Thu 2014-07-10 00:00:13 CEST  8h ago    logrotate.timer              logrotate.service
}}


{{Note|
Ein ''start oder stop'' wirkt sich nur auf die laufende Sitzung aus.
* To list all timers (including inactive), use {{ic|systemctl list-timers --all}}.
* The status of a service started by a timer will likely be inactive unless it is currently being triggered.
* If a timer gets out of sync, it may help to delete its {{ic|stamp-*}} file in {{ic|/var/lib/systemd/timers}}. These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.}}


== Example ==
systemctl reenable --now beispiel.timer
Genügt damit eine nachträgliche Veränderung der Timer-Unit sofort wirksam wird.


No changes to service unit files are needed to schedule them with a timer. The following example schedules {{ic|foo.service}} to be run with a corresponding timer called {{ic|foo.timer}}.  
=== Management ===
systemctl list-timers --all
Listet alle Timer auf. Sollen nur die aktiven Timer angezeigt werden genügt ein ''systemctl list-timers''.


=== Monotonic timer ===


A timer which will start 15 minutes after boot and again every week while the system is running.
Die folgenden Befehle können beim Debuggen helfen:
 
systemctl status beispiel.timer
{{hc|/etc/systemd/system/foo.timer|<nowiki>
[Unit]
Description=Run foo weekly and on boot


[Timer]
journalctl -xe
OnBootSec=15min
OnUnitActiveSec=1w


[Install]
== Optionen ==
WantedBy=timers.target
Die folgende Auflistung der einzelnen Optionen für die Sektionen der {{ic|.timer}} und {{ic|.service}} Dateien will lediglich einen Überblick bieten.
</nowiki>}}


=== Realtime timer ===
Für Details wird auf die jeweilige ''man page'' verwiesen.


A timer which starts once a week (at 12:00am on Monday). It starts once immediately if it missed the last start time (option {{ic|1=Persistent=true}}), for example due to the system being powered off:
Nur die '''fettgedruckten Optionen sind Pflichtangaben ''' der betreffenden Sektion.


{{hc|/etc/systemd/system/foo.timer|<nowiki>
=== Die [Unit] Sektion ===
[Unit]
* '''Description=''' #Hier muss die Einheit beschrieben werden. Die Formulierung ist frei. Auch darf sie in der {{ic|.timer}} und {{ic|.service}} Datei unterschiedlich sein. Kurze, aussagefähige Beschreibungen sind hierbei vorzuziehen.
Description=Run foo weekly
* Documentation= #Eine URL kann hier angegeben werden.
 
* Requires=, Requisite= #Weitere Units können hier angegeben werden.
[Timer]
* Wants= #ein etwas weicheres Requires=
OnCalendar=weekly
* BindsTo= #Auch hier wird eine Unit angegeben. Fällt der service aus, weil z.B. ein device entfernt wurde, wird die Timer-Unit an der Ausführung gehindert.
Persistent=true   
* PartOf= #beim Ausfall eines service stoppt die timer-unit. Jedoch ohne Auswirkungen auf die hier aufgeführten services. 
* Conflicts=
* Before=, After= #legt die Start Reihenfolge von services fest.
* OnFailure= #Ersatz-Units die bei Ausfall genutzt werden sollen.
* PropagatesReloadTo=, ReloadPropagatedFrom= #ähndelt OnFailure=
* JoinsNamespaceOf= #Nur wichtig wenn PrivateNetwork= oder PrivateTmp= eingesetzt wird.
* RequiresMountsFor= #Überprüft ob devices auch gemountet sind.
* OnFailureJobMode=fail, replace (default), replace-irreversibly, isolate, flush, ignore-dependencies, ignore-requirements #legt das Verhalten für OnFailure= fest.         
* IgnoreOnIsolate=true/false #default ist false. Bei true wird nicht mehr gestoppt bei Isolierung einer anderen Unit.
* StopWhenUnneeded=true/false #default ist false. Steht im Zusammenhang mit Requires=. Bei true werden nicht mehr benötigte units deaktiviert.
* RefuseManualStart=true/false, RefuseManualStop=true/false #default ist false. Ein Sicherheitstool. bei true wird die die explizite User Eingabe verlangt, bevor Units de/aktiviert werden können.
* AllowIsolate=true/false #default ist false. Sinnvoll um ähnlich der runlevels in SysV init Systemen um unbestimmte Systemzustände zu vermeiden.
* DefaultDependencies=true/false #Default ist true und stellt sicher, dass das System komplett hochgelaufen ist bevor die timer-unit gestartet wird.
* JobTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument= #stellt bei gestaffelten Jobs ein time-out zur Verfügung.
* StartLimitIntervalSec=, StartLimitBurst= #Als default werden 5 Ausführungen eines service innerhalb von 10 Sekunden zugestanden. Dieses Limit kann hier den speziellen Anforderungen angepasst werden.
* StartLimitAction= #Ein Ersatzservice kann bestimmt werden falls das vereinbarte StartLimitIntervalSec=, StartLimitBurst= überschritten wird. 
* RebootArgument= #Optionales reboot.
* ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable= # Vorbedingung für die Ausführung der Unit.
* AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable= # Wie Condition...allerdings incl. ''logged loudly'' bei failure.
* SourcePath= # Überprüft das Vorhandensein einer Datei.
   
   
[Install]
Genauere Auskunft gibt: {{ic|man systemd.unit}}
WantedBy=timers.target</nowiki>}}


The format controlling {{ic|OnCalendar}} events uses the following format when more specific dates and times are required: {{ic|DayOfWeek Year-Month-Day Hour:Minute:Second}}. An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by {{ic|..}} may be used to indicate a contiguous range. In this example the service is run the first four days of each month at 12:00 PM, but ''only'' if that day is also on a Monday or a Tuesday. More information is available in {{man|7|systemd.time}}.
=== Die [Timer] Sektion ===
Es können hier mehrere Zeitangaben gemacht werden. Mindestens '''eine Zeitangabe muss''' es in [Timer] geben.


OnCalendar=Mon,Tue *-*-01..04 12:00:00
==== Kalendarische Zeitangaben ====
* OnCalendar= #Kalendarische Zeitangabe


{{Tip|Special event expressions like {{ic|daily}} and {{ic|weekly}} refer to ''specific start times'' and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources.  The {{ic|RandomizedDelaySec}} option avoids this problem by randomly staggering the start time of each timer. See {{man|5|systemd.timer}}.}}
===== Absolute Zeitangaben =====


== Transient .timer units ==
OnCalendar=Thu,Fri 2012-*-1..5 11:12:13


One can use {{ic|systemd-run}} to create transient {{ic|.timer}} units. That is, one can set a command to run at a specified time without having a service file. For example the following command touches a file after 30 seconds:
Das obige Beispiel besagt: Um 11:12:13 Uhr, zwischen einschl. dem 1. und 5. Tag, aller Monate, des Jahres 2012, jedoch ausschließlich nur an Donnerstagen und Freitagen.


# systemd-run --on-active=30 /bin/touch /tmp/foo
Die Angabe eines Wochentags erfolgt in Englisch. Sie ist optional.
Jede Rubrik kann mit "," oder ".." versehen werden oder durch "*" ersetzt werden.


One can also specify a pre-existing service file that does not have a timer file. For example, the following starts the systemd unit named {{ic|''someunit''.service}} after 12.5 hours have elapsed:
===== Periodische Zeitangaben =====


  # systemd-run --on-active="12h 30m" --unit ''someunit''.service
  OnCalendar=weekly


See {{man|1|systemd-run}} for more information and examples.
Auch diese Werte sind möglich.
minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually


== As a cron replacement ==
Entsprechend den oberen Werten, kann auch diese Schreibweise genutzt werden.
*-*-* *:*:00, *-*-* *:00:00, *-*-* 00:00:00, *-*-01 00:00:00, Mon *-*-* 00:00:00, *-01-01 00:00:00, *-01,04,07,10-01 00:00:00, *-01,07-01 00:00:00


Although [[cron]] is arguably the most well-known job scheduler, ''systemd'' timers can be an alternative.
==== Relative Zeitangaben ====
Sind abhängig von anderen Ereignissen


=== Benefits ===
Beispiel:
OnBootSec=2d 1h 30m


The main benefits of using timers come from each job having its own ''systemd'' service. Some of these benefits are:
* OnActiveSec= #Zeitspanne seit Aktivierung der Timer-Unit.
* OnBootSec= #Zeitspanne seit dem Booten des Rechners.
* OnStartupSec= #Zeitspanne seit dem Start von systemd.
* OnUnitActiveSec= #Zeitspanne seit der Timer den letzten Job ausgelöst hat.
* OnUnitInactiveSec= #Zeitspanne der Inaktivität seit Beendigung des letzten Jobs.


* Jobs can be easily started independently of their timers. This simplifies debugging.
Folgende Einheiten können für relative Zeitangaben gewählt werden:
* Each job can be configured to run in a specific environment (see {{man|5|systemd.exec}}).
usec, us
* Jobs can be attached to [[cgroups]].
msec, ms
* Jobs can be set up to depend on other ''systemd'' units.
seconds, second, sec, s
* Jobs are logged in the ''systemd'' journal for easy debugging.
minutes, minute, min, m
hours, hour, hr, h
days, day, d
weeks, week, w
months, month, M (definiert als 30.44 Tage)
years, year, y (definiert als 365.25 Tage)
Ohne Verwendung einer Einheit werden alle Angaben als Sekunden gewertet.


=== Caveats ===
==== Weitere Optionen in [Timer] ====
* AccuracySec=  #Die Zeitspanne zum Ausführen beträgt als default 1 Minute. Durch Verwendung von AccuracySec kann diese Zeitspanne variiert werden.
* RandomizedDelaySec= #Kann verwendet werden damit nicht mehrere Timer exakt zur gleichen Zeit loslegen. default ist 0.
* Unit= #Als default ist dieser Wert identisch mit dem Suffix der {{ic|.timer}} Datei. Bei der Verwendung von Unit= muss auch eine Datei mit selbigen Namen erstellt werden. Eine Verschachtelung von Units ist hierdurch möglich. Siehe [http://blog.higgsboson.tk/2013/06/09/use-systemd-as-a-cron-replacement Higgsboson Blog] Reflector
* Persistent=true  #bewirkt, dass ein versäumter Job beim nächsten Rechnerstart unverzüglich nachgeholt wird.
* WakeSystem= #Weckt das System aus dem supend mode.
* RemainAfterElapse=true/false #true hält den Timer aktiv, false beendet den Timer nach einmaliger Ausführung.


Some things that are easy to do with cron are difficult to do with timer units alone.
Weiteres dazu siehe {{ic|man systemd.time}}.


* Complexity: to set up a timed job with ''systemd'' you create two files and run a couple {{ic|systemctl}} commands. Compare that to adding a single line to a crontab.
* Emails: there is no built-in equivalent to cron's {{ic|MAILTO}} for sending emails on job failure. See the next section for an example of setting up a similar setup using {{ic|1=OnFailure=}}.


=== MAILTO ===
=== Die [Install] Sektion ===
* Alias= #Aliasnamen der Unit. Wird nicht von jedem Type unterstützt.
* '''WantedBy='''basic.target, bluetooth.target, getty.target, multi-user.target, printer.target, sockets.target #Bei der ersten Initialisierung der Timer-Unit wird ein symbolischen Link von /etc/systemd/system/basic.target.wants/ angelegt. Erst dann ist die Unit aktiv.
* RequiredBy= #entspricht WantetBy=.
* Also= #installiert oder deinstalliert andere Units bei Aktivierung dieser Unit.
* DefaultInstance= #Regelt den expliziten Einsatz von Vorlage Unit Dateien.


You can set up systemd to send an e-mail when a unit fails. Cron sends mail to {{ic|MAILTO}} the job outputs to stdout or stderr, but many jobs are setup to only output on error. First you need two files: an executable for sending the mail and a ''.service'' for starting the executable. For this example, the executable is just a shell script using {{ic|sendmail}}:
Näheres dazu siehe {{ic|man systemd.unit}} und {{ic|man systemd.special}}.


{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/bash
=== Die [Service] Sektion ===


/usr/bin/sendmail -t <<ERRMAIL
* Type=simple (default), forking, oneshot, dbus, notify, idle.
To: $1
** PIDFile= #In Zusammenhang mit Type=forking kann für den Fork eine PID hinterlegt werden.
From: systemd <root@$HOSTNAME>
** BusName= #Bei Type=dbus kann hier der betreffende D-Bus Name vereinbart werden.
Subject: $2
** NotifyAccess= none (default), main, all. #Steuert den ''service status notification socket''.
Content-Transfer-Encoding: 8bit
* '''ExecStart=''' #Angabe von einem oder mehrerer Befehle und deren Argumente oder eines ausführbaren Scripts. Die absolute Pfadangabe wird verlangt.
Content-Type: text/plain; charset=UTF-8
** ExecStartPre=, ExecStartPost= #Hier aufgeführte Befehle werden vor bzw. nach ExecStart= ausgeführt.
** ExecReload=# Wind genutzt um eine Rekonfiguration des Service zu veranlassen.
** ExecStop= #Wird benötigt falls der Service zum Beenden spezielle Befehle braucht.
*** ExecStopPost= #Ergänzt ExecStop=
** RemainAfterExit= #no (default), yes hält den service aktiv.
** PermissionsStartOnly= #Default ist false. True erlaubt unter ExecStart= Befehle mit anderen Benutzerrechten ausführen zu lassen als die Komandos bei ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, und ExecStopPost=.
* GuessMainPID= #Default ist yes. Wenn die PID nicht exakt bestimmt werden kann wird normalerweise versucht sie zu berechnen. Dies kann hier ausgeschaltet werden.
* TimeoutSec=, TimeoutStartSec=, TimeoutStopSec= #Legt ein Timeout für den Service fest.
* RuntimeMaxSec= #Begrenzt die Laufzeit eines Service. Default ist unbegrenzte Zeit.
* WatchdogSec= #Überwacht den Service auf Aktivität.
* Restart= no (default), on-success, on-failure, on-abnormal, on-watchdog, on-abort, always #Startet den Service erneut.
** RestartSec= #wird nur für Restart= gebraucht
* RootDirectoryStartOnly= #Default ist false. True erlaubt das root Verzeichnis selektiv für ExecStart= Befehle neu zu definieren.
* Sockets= #Siehe {{ic|man systemd.socket}}
** NonBlocking=  #Default ist false. Siehe Näheres {{ic|man systemd.socket}}
* FailureAction= #Aktion nach Scheitern des Service. Default ist none.
* FileDescriptorStoreMax= #Anzahl der Datei Descriptoren. Default ist 0.
* USBFunctionDescriptors= #Betrifft USB-Sticks.
* USBFunctionStrings= #Betrifft USB-Sticks.


$(systemctl status --full "$2")
Näheres dazu siehe {{ic|man systemd.service}}.
ERRMAIL</nowiki>}}


Whatever executable you use, it should probably take at least two arguments as this shell script does: the address to send to and the unit file to get the status of. The ''.service'' we create will pass these arguments:
== MailTo ==


{{hc|/etc/systemd/system/status-email-''user''@.service|2=[Unit]
Die Optionen zum Versenden von Mails beim Ausführen der Services wird bestens im englischen Wiki beschrieben: [https://wiki.archlinux.org/index.php/Systemd/Timers#MAILTO]
Description=status email for %i to ''user''


[Service]
== Siehe auch ==
Type=oneshot
* [[systemd]]
ExecStart=/usr/local/bin/systemd-email ''address'' %i
* [[systemd/Eigener Service|Einen eigenen systemd-Service erstellen]]
User=nobody
* [[Automatische Sicherung (Beispiel)]]
Group=systemd-journal}}


Where {{ic|''user''}} is the user being emailed and {{ic|''address''}} is that user's email address. Although the recipient is hard-coded, the unit file to report on is passed as an instance parameter, so this one service can send email for many other units. At this point you can [[start]] {{ic|status-email-''user''@dbus.service}} to verify that you can receive the emails.
== Weblinks ==
* [https://kofler.info/systemd-timer-als-cron-alternative/ Michael Kofler Blog] Anleitung und Beispiel {{sprache|de}}
* [http://www.techrapid.co.uk/2017/04/automatically-update-arch-linux-with-systemd.html Techrapid Update Archlinux With Systemd] {{sprache|de}} Hinweis: Autoupdates sind nur bedingt zu empfehlen!
* [https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Fedora Project wiki page] on ''systemd'' calendar timers {{sprache|en}}
* [https://wiki.gentoo.org/wiki/Systemd#Timer_services Gentoo wiki section] on ''systemd'' timer services {{sprache|en}}


Then simply [[systemd#Editing provided units|edit]] the service you want emails for and add {{ic|1=OnFailure=status-email-''user''@%n.service}} to the {{ic|[Unit]}} section. {{ic|%n}} passes the unit's name to the template.
[[Kategorie:Systemverwaltung]]
[[Kategorie:Services]]


{{note|
[[en:Systemd/Timers]]
* If you set up SSMTP security according to [[SSMTP#Security]] the user {{ic|nobody}} will not have access to {{ic|/etc/ssmtp/ssmtp.conf}}, and the {{ic|systemctl start status-email-''user''@dbus.service}} command will fail. One solution is to use {{ic|root}} as the User in the {{ic|status-email-''user''@.service}} unit.
[[fr:Systemd/cron]]
* If you try to use {{ic|mail -s somelogs ''address''}} in your email script, {{ic|mail}} will fork and systemd will kill the mail process when it sees your script exit. Make the mail non-forking by doing {{ic|mail -Ssendwait -s somelogs ''address''}}.}}
[[ja:Systemd/タイマー]]
 
[[ru:Systemd/Timers]]
=== Using a crontab ===
 
Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers. {{AUR|systemd-cron-next}} and {{AUR|systemd-cron}} are two such packages. These can provide the missing {{ic|MAILTO}} feature.
 
If you like crontabs just because they provide a unified view of all scheduled jobs, {{ic|systemctl}} can provide this. See [[#Management]].
 
== See also ==
 
* {{man|5|systemd.timer}}
* [https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Fedora Project wiki page] on ''systemd'' calendar timers
* [https://wiki.gentoo.org/wiki/Systemd#Timer_services Gentoo wiki section] on ''systemd'' timer services
* {{App|systemd-cron-next|tool to generate timers/services from crontab and anacrontab files|https://github.com/systemd-cron/systemd-cron-next|{{Aur|systemd-cron-next}}}}
* {{App|systemd-cron|provides systemd units to run cron scripts; using ''systemd-crontab-generator'' to convert crontabs|https://github.com/systemd-cron/systemd-cron|{{Aur|systemd-cron}}}}

Aktuelle Version vom 21. April 2019, 08:55 Uhr

Timer bieten die Möglichkeit Aufgaben zeitlich zu steuern. Die Timer-Unit besteht aus einer .timer Datei die eine .service Datei ansteuert. Timer unterstehen systemd und müssen mit dem systemctl Befehl aktiviert werden. Eine Alternative hierzu bietet cron.

Beispiel

Die .timer Datei

# Datei /etc/systemd/system/beispiel.timer

[Unit]
Description=Beispielaktion nach 1St 30Min

[Timer]
OnBootSec=1h 30m

[Install]
WantedBy=basic.target

Die .service Datei

# Datei /etc/systemd/system/beispiel.service

[Unit]
Description=Beispiel Service

[Service]
ExecStart=/home/<user>/beispiel.sh

Dieses Beispiel stellt eine Minimalvariante der Dateien dar. Weiteres siehe Systemd/Timers#Optionen.

Als [Service] kann ein Befehl oder ein ausführbares Script genutzt werden.

Service- und Timerdatei werden mit root Rechten in /etc/systemd/system/ abgelegt und müssen vor dem . (Punkt) den gleichen Namen tragen.

De-/Aktivierung

systemctl enable --now beispiel.timer

(Bei der ersten Initialisierung legt das System automatisch einen symlink /etc/systemd/system/basic.target.wants/ → /etc/systemd/system/ der .timer Datei an.)

Mit enable --now startet der Timer unverzüglich und permanent, sodass er auch nach einem Neustart aktiv ist.

Ohne --now werden enable oder disable erst nach einem reboot wirksam.

Ein start oder stop wirkt sich nur auf die laufende Sitzung aus. 

systemctl reenable --now beispiel.timer

Genügt damit eine nachträgliche Veränderung der Timer-Unit sofort wirksam wird.

Management

systemctl list-timers --all

Listet alle Timer auf. Sollen nur die aktiven Timer angezeigt werden genügt ein systemctl list-timers.


Die folgenden Befehle können beim Debuggen helfen: 

systemctl status beispiel.timer

journalctl -xe

Optionen

Die folgende Auflistung der einzelnen Optionen für die Sektionen der .timer und .service Dateien will lediglich einen Überblick bieten.

Für Details wird auf die jeweilige man page verwiesen.

Nur die fettgedruckten Optionen sind Pflichtangaben der betreffenden Sektion.

Die [Unit] Sektion

  • Description= #Hier muss die Einheit beschrieben werden. Die Formulierung ist frei. Auch darf sie in der .timer und .service Datei unterschiedlich sein. Kurze, aussagefähige Beschreibungen sind hierbei vorzuziehen.
  • Documentation= #Eine URL kann hier angegeben werden.
  • Requires=, Requisite= #Weitere Units können hier angegeben werden.
  • Wants= #ein etwas weicheres Requires=
  • BindsTo= #Auch hier wird eine Unit angegeben. Fällt der service aus, weil z.B. ein device entfernt wurde, wird die Timer-Unit an der Ausführung gehindert.
  • PartOf= #beim Ausfall eines service stoppt die timer-unit. Jedoch ohne Auswirkungen auf die hier aufgeführten services.
  • Conflicts=
  • Before=, After= #legt die Start Reihenfolge von services fest.
  • OnFailure= #Ersatz-Units die bei Ausfall genutzt werden sollen.
  • PropagatesReloadTo=, ReloadPropagatedFrom= #ähndelt OnFailure=
  • JoinsNamespaceOf= #Nur wichtig wenn PrivateNetwork= oder PrivateTmp= eingesetzt wird.
  • RequiresMountsFor= #Überprüft ob devices auch gemountet sind.
  • OnFailureJobMode=fail, replace (default), replace-irreversibly, isolate, flush, ignore-dependencies, ignore-requirements #legt das Verhalten für OnFailure= fest.
  • IgnoreOnIsolate=true/false #default ist false. Bei true wird nicht mehr gestoppt bei Isolierung einer anderen Unit.
  • StopWhenUnneeded=true/false #default ist false. Steht im Zusammenhang mit Requires=. Bei true werden nicht mehr benötigte units deaktiviert.
  • RefuseManualStart=true/false, RefuseManualStop=true/false #default ist false. Ein Sicherheitstool. bei true wird die die explizite User Eingabe verlangt, bevor Units de/aktiviert werden können.
  • AllowIsolate=true/false #default ist false. Sinnvoll um ähnlich der runlevels in SysV init Systemen um unbestimmte Systemzustände zu vermeiden.
  • DefaultDependencies=true/false #Default ist true und stellt sicher, dass das System komplett hochgelaufen ist bevor die timer-unit gestartet wird.
  • JobTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument= #stellt bei gestaffelten Jobs ein time-out zur Verfügung.
  • StartLimitIntervalSec=, StartLimitBurst= #Als default werden 5 Ausführungen eines service innerhalb von 10 Sekunden zugestanden. Dieses Limit kann hier den speziellen Anforderungen angepasst werden.
  • StartLimitAction= #Ein Ersatzservice kann bestimmt werden falls das vereinbarte StartLimitIntervalSec=, StartLimitBurst= überschritten wird.
  • RebootArgument= #Optionales reboot.
  • ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable= # Vorbedingung für die Ausführung der Unit.
  • AssertArchitecture=, AssertVirtualization=, AssertHost=, AssertKernelCommandLine=, AssertSecurity=, AssertCapability=, AssertACPower=, AssertNeedsUpdate=, AssertFirstBoot=, AssertPathExists=, AssertPathExistsGlob=, AssertPathIsDirectory=, AssertPathIsSymbolicLink=, AssertPathIsMountPoint=, AssertPathIsReadWrite=, AssertDirectoryNotEmpty=, AssertFileNotEmpty=, AssertFileIsExecutable= # Wie Condition...allerdings incl. logged loudly bei failure.
  • SourcePath= # Überprüft das Vorhandensein einer Datei.

Genauere Auskunft gibt: man systemd.unit

Die [Timer] Sektion

Es können hier mehrere Zeitangaben gemacht werden. Mindestens eine Zeitangabe muss es in [Timer] geben.

Kalendarische Zeitangaben

  • OnCalendar= #Kalendarische Zeitangabe
Absolute Zeitangaben
OnCalendar=Thu,Fri 2012-*-1..5 11:12:13

Das obige Beispiel besagt: Um 11:12:13 Uhr, zwischen einschl. dem 1. und 5. Tag, aller Monate, des Jahres 2012, jedoch ausschließlich nur an Donnerstagen und Freitagen.

Die Angabe eines Wochentags erfolgt in Englisch. Sie ist optional. Jede Rubrik kann mit "," oder ".." versehen werden oder durch "*" ersetzt werden.

Periodische Zeitangaben
OnCalendar=weekly

Auch diese Werte sind möglich. 

minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually

Entsprechend den oberen Werten, kann auch diese Schreibweise genutzt werden. 

*-*-* *:*:00, *-*-* *:00:00, *-*-* 00:00:00, *-*-01 00:00:00, Mon *-*-* 00:00:00, *-01-01 00:00:00, *-01,04,07,10-01 00:00:00, *-01,07-01 00:00:00

Relative Zeitangaben

Sind abhängig von anderen Ereignissen

Beispiel: 

OnBootSec=2d 1h 30m
  • OnActiveSec= #Zeitspanne seit Aktivierung der Timer-Unit.
  • OnBootSec= #Zeitspanne seit dem Booten des Rechners.
  • OnStartupSec= #Zeitspanne seit dem Start von systemd.
  • OnUnitActiveSec= #Zeitspanne seit der Timer den letzten Job ausgelöst hat.
  • OnUnitInactiveSec= #Zeitspanne der Inaktivität seit Beendigung des letzten Jobs.

Folgende Einheiten können für relative Zeitangaben gewählt werden: 

usec, us
msec, ms
seconds, second, sec, s
minutes, minute, min, m
hours, hour, hr, h
days, day, d
weeks, week, w
months, month, M (definiert als 30.44 Tage)
years, year, y (definiert als 365.25 Tage)

Ohne Verwendung einer Einheit werden alle Angaben als Sekunden gewertet.

Weitere Optionen in [Timer]

  • AccuracySec= #Die Zeitspanne zum Ausführen beträgt als default 1 Minute. Durch Verwendung von AccuracySec kann diese Zeitspanne variiert werden.
  • RandomizedDelaySec= #Kann verwendet werden damit nicht mehrere Timer exakt zur gleichen Zeit loslegen. default ist 0.
  • Unit= #Als default ist dieser Wert identisch mit dem Suffix der .timer Datei. Bei der Verwendung von Unit= muss auch eine Datei mit selbigen Namen erstellt werden. Eine Verschachtelung von Units ist hierdurch möglich. Siehe Higgsboson Blog Reflector
  • Persistent=true #bewirkt, dass ein versäumter Job beim nächsten Rechnerstart unverzüglich nachgeholt wird.
  • WakeSystem= #Weckt das System aus dem supend mode.
  • RemainAfterElapse=true/false #true hält den Timer aktiv, false beendet den Timer nach einmaliger Ausführung.

Weiteres dazu siehe man systemd.time.


Die [Install] Sektion

  • Alias= #Aliasnamen der Unit. Wird nicht von jedem Type unterstützt.
  • WantedBy=basic.target, bluetooth.target, getty.target, multi-user.target, printer.target, sockets.target #Bei der ersten Initialisierung der Timer-Unit wird ein symbolischen Link von /etc/systemd/system/basic.target.wants/ angelegt. Erst dann ist die Unit aktiv.
  • RequiredBy= #entspricht WantetBy=.
  • Also= #installiert oder deinstalliert andere Units bei Aktivierung dieser Unit.
  • DefaultInstance= #Regelt den expliziten Einsatz von Vorlage Unit Dateien.

Näheres dazu siehe man systemd.unit und man systemd.special.

Die [Service] Sektion

  • Type=simple (default), forking, oneshot, dbus, notify, idle.
    • PIDFile= #In Zusammenhang mit Type=forking kann für den Fork eine PID hinterlegt werden.
    • BusName= #Bei Type=dbus kann hier der betreffende D-Bus Name vereinbart werden.
    • NotifyAccess= none (default), main, all. #Steuert den service status notification socket.
  • ExecStart= #Angabe von einem oder mehrerer Befehle und deren Argumente oder eines ausführbaren Scripts. Die absolute Pfadangabe wird verlangt.
    • ExecStartPre=, ExecStartPost= #Hier aufgeführte Befehle werden vor bzw. nach ExecStart= ausgeführt.
    • ExecReload=# Wind genutzt um eine Rekonfiguration des Service zu veranlassen.
    • ExecStop= #Wird benötigt falls der Service zum Beenden spezielle Befehle braucht.
      • ExecStopPost= #Ergänzt ExecStop=
    • RemainAfterExit= #no (default), yes hält den service aktiv.
    • PermissionsStartOnly= #Default ist false. True erlaubt unter ExecStart= Befehle mit anderen Benutzerrechten ausführen zu lassen als die Komandos bei ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, und ExecStopPost=.
  • GuessMainPID= #Default ist yes. Wenn die PID nicht exakt bestimmt werden kann wird normalerweise versucht sie zu berechnen. Dies kann hier ausgeschaltet werden.
  • TimeoutSec=, TimeoutStartSec=, TimeoutStopSec= #Legt ein Timeout für den Service fest.
  • RuntimeMaxSec= #Begrenzt die Laufzeit eines Service. Default ist unbegrenzte Zeit.
  • WatchdogSec= #Überwacht den Service auf Aktivität.
  • Restart= no (default), on-success, on-failure, on-abnormal, on-watchdog, on-abort, always #Startet den Service erneut.
    • RestartSec= #wird nur für Restart= gebraucht
  • RootDirectoryStartOnly= #Default ist false. True erlaubt das root Verzeichnis selektiv für ExecStart= Befehle neu zu definieren.
  • Sockets= #Siehe man systemd.socket
    • NonBlocking= #Default ist false. Siehe Näheres man systemd.socket
  • FailureAction= #Aktion nach Scheitern des Service. Default ist none.
  • FileDescriptorStoreMax= #Anzahl der Datei Descriptoren. Default ist 0.
  • USBFunctionDescriptors= #Betrifft USB-Sticks.
  • USBFunctionStrings= #Betrifft USB-Sticks.

Näheres dazu siehe man systemd.service.

MailTo

Die Optionen zum Versenden von Mails beim Ausführen der Services wird bestens im englischen Wiki beschrieben: [1]

Siehe auch

Weblinks

Abgerufen von „https://wiki.archlinux.de/index.php?title=Systemd/Timers&oldid=21059“