Version vom 17. März 2017, 02:03 Uhr von Tuxnix (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{inuse|~~~}} {{Lowercase title}} Category:Daemons and system services Category:Boot process de:Systemd/Timers fr:Systemd/cron ja:Systemd/タ…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Construction.png „Systemd/Timers“ wurde von Tuxnix (Diskussion) als in Bearbeitung markiert. Um Bearbeitungskonflikte zu vermeiden, kontaktiere Tuxnix (Diskussion) bitte, bevor du den Artikel bearbeitest.

Vorlage:Lowercase title zh-hans:Systemd/Timers Vorlage:Related articles start Vorlage:Related Vorlage:Related Vorlage:Related Vorlage:Related Vorlage:Related articles end Timer bieten die Möglichkeit Aufgaben zeitgerecht zu steuern. Sie bestehen aus einer .timer und einer .service Datei. Der Timer Dienst wird von systemd gesteuert und müssen mit einem systemctl Befehl aktiviert werden. Alternativen sind cron und anacron.


Dies ist mein erster Archwicki Artikel. Er ist gerade erst im entstehen Der englische Archwikiartikel dient lediglich als Vorlage.


.timer Datei

.service Datei


Timer units

Timers are like other unit configuration files and are loaded from the same paths but include a [Timer] section. The [Timer] section defines when and how the timer activates. Timers are defined as one of two types:

  • 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: OnTypeSec=. OnBootSec and OnActiveSec are common monotonic timers.
  • Realtime timers (a.k.a. wallclock timers) activate on a calendar event (like cronjobs). The option OnCalendar= is used to define them.

For a full explanation of timer options, see the Vorlage:Man. The argument syntax for calendar events and time spans is defined in Vorlage:Man.

Service unit

For each .timer file, a matching .service file exists (e.g. foo.timer and foo.service). The .timer file activates and controls the .service file. The .service does not require an [Install] section as it is the timer units that are enabled. If necessary, it is possible to control a differently-named unit using the Unit= option in the timer's [Timer] section.


To use a timer unit enable and start it like any other unit (remember to add the .timer suffix). To view all started timers, run:

$ systemctl list-timers
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



No changes to service unit files are needed to schedule them with a timer. The following example schedules foo.service to be run with a corresponding timer called foo.timer.

Monotonic timer

A timer which will start 15 minutes after boot and again every week while the system is running.

Description=Run foo weekly and on boot



Realtime timer

A timer which starts once a week (at 12:00am on Monday). It starts once immediately if it missed the last start time (option Persistent=true), for example due to the system being powered off:

Description=Run foo weekly


The format controlling OnCalendar events uses the following format when more specific dates and times are required: 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 .. 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 Vorlage:Man.

OnCalendar=Mon,Tue *-*-01..04 12:00:00


Transient .timer units

One can use systemd-run to create transient .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:

# systemd-run --on-active=30 /bin/touch /tmp/foo

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 someunit.service after 12.5 hours have elapsed:

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

See Vorlage:Man for more information and examples.

As a cron replacement

Although cron is arguably the most well-known job scheduler, systemd timers can be an alternative.


The main benefits of using timers come from each job having its own systemd service. Some of these benefits are:

  • Jobs can be easily started independently of their timers. This simplifies debugging.
  • Each job can be configured to run in a specific environment (see Vorlage:Man).
  • Jobs can be attached to cgroups.
  • Jobs can be set up to depend on other systemd units.
  • Jobs are logged in the systemd journal for easy debugging.


Some things that are easy to do with cron are difficult to do with timer units alone.

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


You can set up systemd to send an e-mail when a unit fails. Cron sends mail to 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 sendmail:


/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")

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:

Description=status email for %i to user

ExecStart=/usr/local/bin/systemd-email address %i

Where user is the user being emailed and 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 status-email-user@dbus.service to verify that you can receive the emails.

Then simply edit the service you want emails for and add OnFailure=status-email-user@%n.service to the [Unit] section. %n passes the unit's name to the template.


Using a crontab

Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers. systemd-cron-nextAUR and systemd-cronAUR are two such packages. These can provide the missing MAILTO feature.

If you like crontabs just because they provide a unified view of all scheduled jobs, systemctl can provide this. See #Management.

See also