Timers and Your Own Services

Why a timer

The Shell course ended with a nightly backup run by cron, from a crontab line. systemd timers do the same job, and add a few things cron can’t ¹:

• Catching up. If the computer was off or asleep at 2:30, cron skips that night. A timer with Persistent=true runs as soon as the computer is back ².
• Logging. Everything the job prints goes to the journal, with no >> backup.log 2>&1 to remember ¹.
• Testing. The job is an ordinary service: start it by hand any time, check its status, read its log ¹.

The price is two small files instead of one line ¹. Ubuntu itself uses timers: the daily apt-daily and apt-daily-upgrade runs from last module are timers ³.

The service

A timer starts a service, so write the service first. This one is a user unit, run by your own user manager without sudo; user units you write go in ~/.config/systemd/user/ ⁴. Create ~/.config/systemd/user/snapshot-backup.service:

[Unit]
Description=Snapshot backup to the backup drive

[Service]
Type=oneshot
ExecStart=%h/.local/bin/snapshot-backup /media/%u/backup

• Type=oneshot is for a job that runs and finishes, rather than a program that keeps running; systemd treats the service as done when the command exits ⁵.
• ExecStart= is the command, with a full path. %h stands for your home folder and %u for your user name, so the file works for any user ⁶.
• No [Install] section: the timer is what gets enabled ¹.

The timer

Now ~/.config/systemd/user/snapshot-backup.timer, with the same name apart from the ending, since a timer starts the service with its own name by default ²:

[Unit]
Description=Nightly snapshot backup

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

• OnCalendar= sets a wall-clock time, like a crontab line ². *-*-* 02:30:00 is any year, month, and day at 2:30.
• Persistent=true stores when the timer last fired; when the timer starts up again (after boot or after you log in), it runs the service straight away if a run was missed in the meantime ².
• WantedBy=timers.target in [Install] is what enable hooks into, so the timer starts automatically. timers.target exists in the user manager as well as the system one ⁷.

Calendar expressions

The full form is DayOfWeek Year-Month-Day Hour:Minute:Second, with * for “any” and leading parts optional ⁸. Some examples:

hourly, daily, weekly, monthly, and yearly are shorthands for those forms ⁸. Don’t guess; check with systemd-analyze calendar, which prints the normalized form and when it would next fire. The manual’s example finds the next leap days ⁹:

$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
  Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
    Next elapse: Sat 2020-02-29 00:00:00 UTC
       From now: 11 months 15 days left
       Iter. #2: Thu 2024-02-29 00:00:00 UTC
       From now: 4 years 11 months left
...

Turning it on

me@garden-laptop:~$ systemctl --user daemon-reload
me@garden-laptop:~$ systemctl --user enable --now snapshot-backup.timer
me@garden-laptop:~$ systemctl --user list-timers

daemon-reload makes the user manager read the new files; enable --now sets the timer to start at login and starts it now; list-timers shows each timer with its NEXT and LAST run times and the unit it ACTIVATES ¹. Run systemctl list-timers without --user to see the system’s own, apt-daily among them.

Testing it

Don’t wait until 2:30. The job is a service, so start it now:

me@garden-laptop:~$ systemctl --user start snapshot-backup.service
me@garden-laptop:~$ systemctl --user status snapshot-backup.service
me@garden-laptop:~$ journalctl --user -u snapshot-backup.service

With Type=oneshot, start waits until the backup finishes. The journal then holds everything the script printed, and its exit status: a failure shows in status as failed, and in systemctl --user list-units --failed ⁵. If the drive isn’t plugged in, the script’s own check stops it and says so, and that message is in the journal too.

Once it works, remove the old line with crontab -e, so the backup doesn’t run twice.

While you’re logged out

A user timer runs in your user manager, which by default exists only while you’re logged in ¹. To keep it running from boot, logged in or not, turn on lingering ^{10 4}:

me@garden-laptop:~$ loginctl enable-linger

One catch for this particular job: a USB drive shows up under /media/<you>/ because your desktop mounts it when you’re logged in. With nobody logged in, it isn’t mounted, and the script will (correctly) refuse to run. The fix is to have the system mount the drive itself, at a fixed place, which is part of next module.

System timers

For jobs that need root, such as backing up /etc or the whole system, the same two files go in /etc/systemd/system/ and are managed with sudo systemctl, without --user ⁶. Everything else is identical. Prefer user units for your own files: they run as you, so a mistake can’t damage the rest of the system.

Your turn

So

A systemd timer is a .timer unit that starts a .service of the same name. Put your own in ~/.config/systemd/user/; use Type=oneshot and a full path in ExecStart= (with %h and %u), and OnCalendar= plus Persistent=true in the timer so missed runs catch up. Check expressions with systemd-analyze calendar, turn it on with systemctl --user daemon-reload and enable --now, see it in list-timers, test it by starting the service, and read the result with journalctl --user -u. loginctl enable-linger keeps it running while you’re logged out.