Winding Up the Clock

If you want Systemd to activate the timer directly at system startup, you need an [Install] section in the timer unit. The WantedBy= setting tells which other units the timer should start with. In Listing 2, the WantedBy=timers.target setting ensures that Systemd starts the timer together with all other timers at the regular system startup time.

If you want Systemd to start the timer at startup time, you have to enable it explicitly (Listing 4, first line). Alternatively, you can start the timer manually (second line). All currently configured timers are listed by the systemctl list-timers command (Figure 2).

$ systemctl enable backup.timer
$ systemctl start backup.timer

Figure 2: Systemctl displays all timers currently running. The display requires the widest possible terminal; alternatively, you can use systemctl list-timers --no-pager to output the information to the standard output.

In the table under Next, you can read when the system timer will execute the task the next time. The time remaining until then is in the Left column. Similarly, you can see under Load when systemd-timer last executed the task. How long ago that was is shown in the Passed column. Under Unit, you will find the name of the corresponding timer and thus its configuration file.

You can end the display by pressing [Q]. By default, Systemctl only presents timers that are currently enabled. You can display the inactive timers on screen by appending the --all parameter.

Snooze Button

If required, each timer can be stopped manually (Listing 5, first line) and disabled (second line). The manpage [1], which goes by the name of systemd.timer, provides explanations for all presented settings. man systemd.time provides further information on the format of dates and times and offers numerous additional examples.

$ sudo systemctl stop my.timer
$ sudo systemctl disable my.timer

Short-Term Alarm

If you want Systemd to make a single backup in exactly 30 minutes, use systemd-run. The command looks like the first line of Listing 6. The /usr/bin/backup.sh /mnt command appended there is executed by Systemd at the specified time. Use the parameter --on-active to tell it the waiting time.

$ systemd-run --on-active=30m /usr/bin/backup.sh /mnt
$ systemd-run --on-calendar=weekly --unit backup.service

The time units again correspond to those in Table 1. In the example, Systemd interprets the 30m as half an hour. Alternatively, use --on-calendar= to enter a specific date. The details are again provided in the same way as in the timer unit. With appropriate time specifications such as weekly, the action can execute repeatedly.

In any case, systemd-run creates a new timer in the background without you needing to create a service file (Figure 3). If a suitable service unit already exists, you can alternatively let systemd-run launch it. To do this, simply pass in the name of the service unit using the --unit parameter. The example from the second line of Listing 6 starts the task stored in the backup.service service unit every week.

Figure 3: The timers generated by systemd-run have cryptic names that typically do not indicate the task solved by the timer.

The timers generated by systemd-run only exist temporarily. If you use the --on-active parameter, the timer disappears immediately after the action has been executed; in any case, it disappears after rebooting the system. systemd-run only creates a timer for a service unit if no suitable timer unit exists.