Differences between revisions 3 and 4
Revision 3 as of 2019-07-30 05:23:36
Size: 8175
Editor: ?NickBannon
Comment: systemd-cron
Revision 4 as of 2019-07-30 05:39:46
Size: 8196
Editor: ?NickBannon
Comment: units
Deletions are marked like this. Additions are marked like this.
Line 66: Line 66:
 * sequential run-parts jobs for each of /etc/cron.d{daily,weekly,monthly}
 * individual, parallel jobs for scripts in cron.d
 * sequential, serial run-parts timer units for each of /etc/cron.{daily,weekly,monthly}
 * individual, parallel timer units for scripts in cron.d

Time-based job scheduling in Debian (cron and friends)


time-based job scheduling is integral part of most operating systems. In the UNIX world, this is usually accomplished by a program called cron. Since it's so old, its functions have diverged and developed. Most cron implementations, including the one used in Debian, are based on the ancient Vixie Cron, named for its author, Paul Vixie. Vixie Cron didn't see an upstream release in two decades. Wikipedia says that in 2004, vixie cron 4.1 was renamed to ISC cron, but for historical reasons, Debian's cron has stayed based on Vixie cron 3.0pl1 up to today.

A multitude of enhancements and accompanying software has surfaced, and time-based job scheduling is today one of the places where different Linux distributions do actually still differ from each other. This article tries to summarize the situation and was motivated by a short debian-devel thread about the current state of affairs. This Wiki Page is rather new (written on 2019-07-24). Feel free to point out errors and fix them.

Chapter 9.5 of the Debian Policy Manual gives additional input.


A Debian system has the following cron tab files:

  • /etc/crontab, usually only holding entries to run the jobs from /etc/cron.{daily,weekly,monthly}. Packages MUST NOT touch this file according to Policy.
  • /var/spool/cron/crontabs, holding a crontab per user. These crontabs usually get maintained via the crontab(1) tool. root's "personal" crontab is a great place to hide jobs you will never find again.
  • Files from /etc/cron.d/ are considered as additions to the global /etc/crontab and treated the same. This allows both packages and the local administrator to drop in system-wide cron jobs without having to modify /etc/crontab. This, for example, is a Debian addition and not supported in plain Vixie cron (should you still find one).

The directories /etc/cron.{daily,weekly,monthly} contain scripts (not crontabs!) that get executed sequentially in lexical sort order via run-parts from /etc/crontab in the respective intervals. It is currently unknown whether there are packages that depend on the lexical sort order of cron jobs to be executed.

Software currently in Debian

Package maintainers of cron-related software, please feel free to add a section about your software. The list given here is most probably incomplete and omission doesn't imply an opinion.


This is the cron package that gets installed on Debian systems if the local admin does not explicitly install a different one. It's a heavily patched Vixie Cron 3.0pl1 and has been this way since Debian's beginning, the first changelog entry being 3.0pl1-35 from 1996. For example, an @reboot time has been added to allow processes to run after the system was brought up.

If a system is not up and running at the time a cron job is scheduled to run, the job is not executed, which makes this version of cron hard to use on personal machines that get turned off or sent to sleep at night. This is also a challenge for a server that crashed at night and gets rebooted on the next day.

Any standard output and standard error output of a cron job executed by cron is e-mailed to the address that the MAILTO variable in the crontab points to.

A plain cron installation in Debian runs the daily cron job at 06:25, the weekly ones at 06:47 and the monthly ones at 06:52.

The cron package is currently maintained in the Debian project on salsa by a small team, but does only get the minimum of maintenance. It is still packaged in source format 1, which makes it hard to track the Debian modifications. There is effort going on to convert the package to the 3.0 (quilt) format (which is not yet visible in git).

It is also planned to organize the migration from cron/anacron to cronie on a mailing list (not yet created).


Anacron is the canonical way to run at least the jobs from /etc/cron.{daily,weekly,monthly) after startup, even when their execution was missed because the system was not running at the given time. Anacron does not handle any cron jobs from /etc/cron.d, so any package that wants its /etc/cron.d cronjob being executed by anacron needs to take special measures.

If anacron is installed, regular processing of the /etc/cron.d{daily,weekly,monthly} is omitted by code in /etc/crontab but handled by anacron via /etc/anacrontab. Anacron's execution of these job lists has changed multiple times in the past:

  • In wheezy and earlier, anacron is executed via init script on startup and via /etc/cron.d at 07:30. This causes the jobs to be run in order, if scheduled, beginning at 07:35. If the system is rebooted between midnight and 07:35, the jobs run after five minutes of uptime.
  • In stretch, anacron is executed via a systemd timer every hour, including the night hours. This causes the jobs to be run in order, if scheduled, beween midnight and 01:00, which is a significant change to the previous behavior.
  • In buster, anacron is executed via a systemd timer every hour with the exception of midnight to 07:00 where anacron is not invoked. This brings back a bit of the old timing, with the jobs to be run in order, if scheduled, beween 07:00 and 08:00. Since anacron is also invoked once at system startup, a reboot between midnight and 08:00 also causes the jobs to be scheduled after five minutes of uptime.

anacron also didn't have an upstream release in nearly two decades and is also currently orphaned in Debian.

As of 2019-07 (right after buster's release) it is planned to have cron and anacron replaced by cronie.


Cronie was forked by Red Hat from ISC Cron 4.1 in 2007, is the default cron implementation in Fedora and Red Hat Enterprise Linux at least since Version 6. cronie seems to have an acive upstream, but is currently missing some of the things that Debian has added to vixie cron over the years. With the finishing of cron's conversion to quilt (3.0), effort can begin to add the Debian extensions to Vixie cron to cronie.

Because cronie doesn't have all the Debian extensions yet, it is not yet suitable as a cron replacement.

cronie is currently only in Debian experimental, and also maintained inside Salsa's Debian project. The current plan is to switch from Vixie cron 3.1 to current cronie during the bullseye release cycle, so that bullseye can release with a current cronie replacing the ancient software combination.

systemd timers

Systemd timers are a totally different method for time-based process scheduling. The biggest difference is that systemd timers run independently to each other, probably causing all timers to fire simultaneously unless features like ?RandomizeDelaySec is used, and the jobs run in random order. The output of a systemd timer is not e-mailed, but goes into the journal.

There is a compatibility layer called systemd-cron which comes as a systemd generator building timer units from the crontab files, but the semantics are rather different and it looks like there are no plans to change that. It will generate:

  • sequential, serial run-parts timer units for each of /etc/cron.{daily,weekly,monthly}
  • individual, parallel timer units for scripts in cron.d

It is unlikely that systemd timers will ever be a drop-in replacement for the old-fashioned cron. Packages are free to migrate from cron to systemd timers, but there cannot be a "big bang" time when all cron jobs get replaced by systemd timers without dedicated action by the individual package maintainers.



out of scope

There is also atd which is used to execute a process a single time based on time.