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.

Units for non-persistent jobs from crontab(5)s are generated with sequential names, so if a job changes (by direct editing or by removing (commenting out) a previous job) while it is running, and mail is sent for that job, the metadata (description, name, other configuration) will be wrong (too new). The journal output is correct. Setting CRON_UNIQUE_UNITS will work around this (but break existing systemctl editoverrides).

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)