Difference between revisions of "Systemd/Timers"

From ArchWiki
Jump to navigation Jump to search
(→‎Motivation: consolidate timer features into bulleted list. grammar fixes)
(→‎Parallelization: rw; adding a para on the reasoning behind AccuracySec)
Line 110: Line 110:
  
 
=== Parallelization ===
 
=== Parallelization ===
Currently, there is no built-in way to spread timers out evenly across a given interval. While {{ic|AccuracySec}} is sometimes offered as a solution, the randomization it implies is designed such that it is synchronised between all local timer units, and is not equivalent to cron’s random delay configuration. E.g., all daily timer units with {{ic|1=AccuracySec=15m}} will trigger the associated jobs at the same point in time between 00:00 and 00:15.
+
Currently, there is no built-in way to spread timers out evenly across a given interval. With the related {{ic|AccuracySec}} option, the randomization is designed such that it is synchronised between all local timer units, and is not equivalent to cron’s random delay configuration. For example, all daily timer units with {{ic|1=AccuracySec=15m}} will trigger the associated jobs at the same point in time between 00:00 and 00:15.
 +
 
 +
The grouped trigger was designed like this to minimize system wake-ups through cron jobs and with it energy consumption of the system. For some usecases (e.g. system jobs requiring specific start times) this parallelization may not be desired, for others it may be beneficial.
  
 
== See also ==
 
== See also ==

Revision as of 11:06, 6 October 2014

systemd is capable of taking on a significant subset of functionality of cron with timer events. It has built-in support for both calendar time events and monotonic time events, and has the foundations for being an anacron replacement with the options Persistent and OnCalendar in timers.

Motivation

Although cron is the arguably most well-known job scheduler, its simplicity limits its functionality in several aspects. If you are willing to expend a bit more effort for more full-featured scheduling, systemd provides a good alternative. Some of the benefits of using systemd timers are:

  • Timer activation and job failures are logged in the systemd journal for easy debugging.
  • Jobs are decoupled from their timers. This allows jobs to be easily run independently of their timers, or for multiple timers to trigger a single job.
  • Each job can be configured to run in a specific environment (see the systemd.exec(5) man page).
  • Jobs can be attached to cgroups.
  • Jobs can be set up to depend on other systemd units.

Writing timer units

Timers are systemd unit files with a name ending in .timer. Writing these files follows the common options of all unit configuration files. Please refer to systemd#Writing custom .service files for a quick look at the overall syntax.

The timer specific configuration options are configured in a [Timer] section. There are two ways to define when the timed service will be triggered:

  • time relative to a starting point such as the last boot (using OnBootSec) or the time the service was last activated (using OnUnitActiveSec).
  • time relative to a real time (using OnCalendar).

See systemd.timer(5) for a full list of options available for timer units.

For each .timer file, a matching .service file describing the unit to activate when the timer elapses must exist; by default, this will be a service with the same name as the timer except for the suffix (e.g. foo.timer will activate and control foo.service). It also possible to define a differently named unit to trigger by mentioning Unit=target_unit.service under the [Timer] section.

Management

As the service unit will be started by the timer, the service does not need an [Install] section; instead, you should specify WantedBy=timers.target in the timer's [Install] section and then enable and start it, paying attention to explicitly mention the .timer suffix. Note that the status of the service will be inactive unless it is currently running due to the timer being triggered.

To see active timers with time details, 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

The LAST field information is maintained by systemd through stamp-* files in the /var/lib/systemd/timers directory. These are zero length files of which the time field will be used. In case the timers get out of sync it may help to delete the stamp file. It will be reconstructed by systemd on the next start of this timer.

If you want to stop and/or disable the scheduled service, just stop and/or disable the corresponding timer unit.

Example

Every scheduled task requires its own service file. Our example is a backup script which we will set up to run weekly.

/etc/systemd/system/myBackup.service
[Unit]
Description=full system backup

[Service]
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/path/to/myBackup/script  

There are a couple ways you could make a timer for this service, but the timer must have the same name as the service (i.e. myBackup.timer) or specify Unit=myBackup.service.

Run On Intervals

If you wish to run backups according to a calendar event, use the OnCalendar option. See the systemd.time(7) man page for other scheduling options.

/etc/systemd/system/myBackup.timer
[Unit]
Description=weekly full backup

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target
Tip: As with cron jobs, running multiple heavy services simultaneously can cause poor performance. Using OnCalendar=weekly for multiple services, as described above, would cause all of them to be triggered simultaneously (each Monday at midnight). Consider using a more specific setting to avoid conflicts e.g. OnCalendar=Wed, 23:15. See #Parallelization.

Run After Booting

Alternatively, if you want to run backups every time the system boots and every week while between reboots, you can combine OnBootSec with OnUnitActiveSec.

/etc/systemd/system/myBackup.timer
[Unit]
Description=weekly and post-boot backup

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w 

[Install]
WantedBy=timers.target
Tip: For resource-eating services, do not set the timer too close to boot. It could seriously delay your login and X sessions.

Caveats

This describes a few caveats involved when migrating from cron jobs to systemd timer units.

Parallelization

Currently, there is no built-in way to spread timers out evenly across a given interval. With the related AccuracySec option, the randomization is designed such that it is synchronised between all local timer units, and is not equivalent to cron’s random delay configuration. For example, all daily timer units with AccuracySec=15m will trigger the associated jobs at the same point in time between 00:00 and 00:15.

The grouped trigger was designed like this to minimize system wake-ups through cron jobs and with it energy consumption of the system. For some usecases (e.g. system jobs requiring specific start times) this parallelization may not be desired, for others it may be beneficial.

See also