NAME
systemd.crom — systemd units for cron periodic jobs
SYNOPSIS
cron.target
cron-update.path, cron-update.service
cron-mail@.service
DESCRIPTION
These units provide the functionality usually afforded by the cron daemon — running scripts in /etc/cron.schedule directories and sending mail on failure.
Crontabs are monitored by cron-update.path and are automatically translated by systemd-crontab-generator(8).
FILES
/etc/crontab
Administrator’s system crontab, see crontab(5).
/etc/cron.d
System crontabs managed by packages live here.
/etc/anacrontab
/var/spool/cron/crontabs
Users’ crontabs live here.
/etc/cron.hourly
Directory for scripts to be executed every hour.
/etc/cron.daily
Directory for scripts to be executed every day.
/etc/cron.weekly
Directory for scripts to be executed every week.
/etc/cron.monthly
Directory for scripts to be executed every month.
/etc/cron.yearly
Directory for scripts to be executed every year.
/usr/lib/systemd/system/schedule.timer
/etc/systemd/system/schedule.timer
Native systemd timers will override cron jobs with the same name.
You can also use this mechanism to mask an unneeded crontab provided by a package via systemctl mask package.timer.
UNITS
cron.target
Target unit which starts the others, needs to be enabled to use systemd-cron.
cron-update.path
Monitors FILES and calls
cron-update.service
which runs systemctl daemon-reload to re-run the generator.
cron-mail@.service
Sends mail (via sendmail(1), which can be overridden with $SENDMAIL) in case a cron service unit fails, succeeds, or succeeds-but-only-if-it-wrote-something. The instance name (the bit after the @) is the unit name, followed by optional arguments delimited by colons (’:’):
nonempty
exit silently if the unit produced no output (equivalent to CRON_MAIL_SUCCESS=nonempty) for OnSuccess=),
nometadata
don’t include systemctl status output, don’t add usual journalctl metadata to the output (equivalent to CRON_MAIL_FORMAT=nometadata), and
verbose
log reason before exiting silently.
(upper-case arguments are ignored).
Overriding this via systemctl edit can be useful, especially for units under /etc/cron.*.
BUGS
Do not use with a cron daemon or anacron, otherwise scripts may be executed multiple times.
All services are run with Type=oneshot, which means you can’t use systemd-cron to launch long lived forking daemons.
EXTENSIONS
The generator can optionally turn any crontabs in persistent timers with the PERSISTENT=true flag, while a regular cron and anacron setup won’t catch up on the missed executions of crontabs on reboot.
EXAMPLES
Start cron units
# systemctl start cron.target
Start cron
units on boot
# systemctl enable cron.target
View script
output
# journalctl -u cron-daily
Override some generated timer start time
# systemctl edit cron-geoip-database-contrib-root-1.timer
and add
[Timer]
OnCalendar=
OnCalendar=*-*-* 18:36:00
Override cron-daily.service priority, useful for old computers
# systemctl edit cron-daily.service
and add
[Service]
CPUSchedulingPolicy=idle
IOSchedulingClass=idle
Example
service file executed every hour
[Unit]
Description=Update the man db
[Service]
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/bin/mandb --quiet
[Install]
WantedBy=cron-hourly.target
NOTES
The exact times scripts are executed is determined by the values of the special calendar events hourly, daily, weekly, monthly, and yearly defined in systemd.time(7).
DIAGNOSTICS
systemctl list-timers shows an overview of current timers and when they’ll elapse.
SEE ALSO
crontab(1), systemd(1), crontab(5), systemd.service(5), systemd.timer(5), systemd.unit(5), systemd.time(7), run-parts(8), systemd-crontab-generator(8)
systemd-cron 2.3.4-1 April 2, 2024 systemd-cron 2.3.4-1