SYSTEMD.CRON(7)

NAME
systemd.cron - 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)
@statedir@
    Users' crontabs live here.
/dev/shm/systemd-cron.*
    Queues and tokens used for CRON_BATCH_LOADAVG_BELOW and CRON_BATCH_THROTTLE_GROUP.

/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.

File names of crontabs in /etc/cron.d must not start with a dot (‘’)., end with a tilde (‘~’), or contain ".dpkg-" or ".rpm"; they will be ignored if they do. 0anacron and anacron are always ignored.

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 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.*: set $SENDMAIL or $MAILFROM to override the defaults ((sendmail) 1 and "root", respectively).

    $SENDMAIL can be also be set from the global systemd environment (systemctl show-environment).

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)