systemd is preinstalled on most Linux systems and is commonly
known for being
the destroyer of worlds a constant cause of problems
a rather notoriously difficult system management daemon. I’d like to discuss
some reasons why both timers are essential to someone’s workflow as well as why
systemd should probably be chosen over cron implementations. As per usual, this
is implementation dependent and other software may suit your usecase better.
Timers are useful for running things such as daily backups, alarms, and any other automated system. Automation in general is useful because it removes the human aspect of things, and timer programs such as cron, atd, and systemd timer units can be incredibly useful for this.
An essential component to systemd that is often overlooked is it’s ability to
cron, a timer tool that has a side effect of not running in a logind
session, and therefore can be used to escape resource restrictions and
permissions enforcements due to the way the daemon runs. This unfortunately is
something that happens with all daemons that are started outside of the
user’s systemd session. Because cron is a system-level daemon, it’s not started
in your session.
The Arch Wiki guide has a link here if you would like a more formal introduction to systemd timers.
As an example, we can set a weekly timer to run a program in a binaries directory:
# disco-party.timer [Unit] Description=Run our weekly disco-party program. [Timer] OnCalendar=weekly [Install] WantedBy=default.target # disco-party.service [Unit] Description=Set up a Disco Party [Service] ExecStart=/home/%h/bin/disco-party Type=oneshot
Since this is a user unit, you should use the default target (provided by systemd when a session is ready).
The OnCalendar unit can take the values listed here. While cron used a basic format, defining numbers in order of minute, hour, day, month, and year, systemd instead has a different format:
OnCalendar=[weekday] <day of month>-<year>-<year> <hour>:<minute>:<second>
Any value can be replaced with a star (except for weekday I think, which can be omitted in its entirety) to match “any” value, or a range can be provided. For example, to run a program on weekdays at 5 PM:
OnCalendar=Mon..Fri *-*-* 17:00:00
We can also set up a monotonic seconds-since timer, with various options such as OnActiveSec (seconds since timer was started), OnBootSec (seconds since the system booted), OnStartupSec (seconds since the session started, such as when a user logs in for the first time since reboot), OnUnitActiveSec (seconds since the unit was last activated), and OnUnitDeactiveSec (seconds since the unit was last deactivated).
An example unit, ripped straight out of shell-server:
# ansible-pull.timer [Unit] Description=Run ansible-pull every 15 mins [Timer] OnBootSec=15min OnUnitDeactiveSec=15m [Install] WantedBy=timers.target
Since this is a system-level unit, you should use the timers.target unit, provided by systemd when timers are ready to be run.
Cron Run-Parts Imitation
cron implementations have a
@daily, and similar time options
which closely resemble the
OnCalendar= option above. As such, we can
quickly produce something similar without using
cron. This does require the
run-parts command. source
# crontab.service [Install] WantedBy=multi-user.target [Unit] Description=Simulates cron, limited to /etc/cron.* Requiresemail@example.com Requiresfirstname.lastname@example.org Requiresemail@example.com Requiresfirstname.lastname@example.org # crontab@.service [Unit] Description=%I job for /etc/cron.%I RefuseManualStart=yes RefuseManualStop=yes ConditionDirectoryNotEmpty=/etc/cron.%I [Service] Type=oneshot IgnoreSIGPIPE=no WorkingDirectory=/ ExecStart=/bin/run-parts --report /etc/cron.%I # crontab@.timer [Unit] Description=%I timer simulating /etc/cron.%I PartOf=crontab.target RefuseManualStart=yes RefuseManualStop=yes [Timer] OnCalendar=%I Persistent=yes
This would need to be a system-level unit, which can be enabled by running the
sudo systemd enable --now crontab. To avoid running in duplicate with
cron it is recommended to only do this if
cron is masked, not just
disabled, as future updates can re-enable
cron. You can do this by running
sudo systemd mask cron.
This article is a live post and will be updated if amendment is needed to clarify explanations of certain topics.
EDIT-2020-08-15: Rewrite to be less snarky.