Provided by: systemd-cron_2.4.1-1_amd64
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 anacrontab(5) /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)