Editing Cron (section)

== History ==

=== Early versions ===
The cron in [[Version 7 Unix]] was a system service (later called a [[daemon (computing)|daemon]]) invoked from <code>/etc/rc</code> when the operating system entered multi-user mode.<ref>{{cite web | title=V7/etc/rc | website=Minnie's Home Page | url=http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/etc/rc | access-date=2020-09-12 }}</ref> Its [[algorithm]] was straightforward:
# Read <code>/usr/lib/crontab</code><ref>{{cite web | title=V7/usr/src/cmd/cron.c | website=Minnie's Home Page | url=http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/cron.c | access-date=2020-09-12 }}</ref>
# Determine if any commands must run at the current date and time, and if so, run them as the [[superuser]], root.
# Sleep for one minute
# Repeat from step 1.

This version of cron was basic and robust but it also consumed resources whether it found any work to do or not. In an experiment at [[Purdue University]] in the late 1970s to extend cron's service to all 100 users on a time-shared [[VAX]], it was found to place too much load on the system.

=== Multi-user capability ===
<!--
Note to future authors of this content.  I know more about this version of cron, having invented it, and so recognize that the content is out of balance.  It would be great to elaborate more on the other versions
-->
The next version of cron, with the release of [[UNIX System V|Unix System V]], was created to extend the capabilities of cron to all users of a Unix system, not just the superuser. Though this may seem trivial today with most Unix and Unix-like systems having powerful processors and small numbers of users, at the time it required a new approach on a one-[[instructions per second|MIPS]] system having roughly 100 user accounts.

In the August, 1977 issue of the ''[[Communications of the ACM]]'', W. R. Franta and Kurt Maly published an article titled "An efficient data structure for the simulation event set", describing an event queue data structure for discrete event-driven simulation systems that demonstrated "performance superior to that of commonly used simple linked list algorithms", good behavior given non-uniform time distributions, and worst case [[Analysis of algorithms|complexity]] <math>\theta\left(\sqrt{n}\right)</math>, "n" being the number of events in the queue.

A Purdue graduate student, Robert Brown, reviewing this article, recognized the parallel between cron and [[discrete event simulation|discrete event simulators]], and created an implementation of the Franta–Maly event list manager (ELM) for experimentation.  Discrete event simulators run in ''virtual time'', peeling events off the event queue as quickly as possible and advancing their notion of "now" to the scheduled time of the next event. Running the event simulator in "real time" instead of virtual time created a version of cron that spent most of its time sleeping, waiting for the scheduled time to execute the task at the head of the event list.

The following school year brought new students into the graduate program at Purdue, including Keith Williamson, who joined the systems staff in the Computer Science department. As a "warm up task" Brown asked him to flesh out the prototype cron into a production service, and this multi-user cron went into use at Purdue in late 1979. This version of cron wholly replaced the <code>/etc/cron</code> that was in use on the computer science department's VAX 11/780 running 32/V.

The algorithm used by this cron is as follows:
# On start-up, look for a file named <code>.crontab</code> in the home directories of all account holders.
# For each crontab file found, determine the next time in the future that each command must run.
# Place those commands on the Franta–Maly event list with their corresponding time and their "five field" time specifier.
# Enter main loop:
## Examine the task entry at the head of the queue, compute how far in the future it must run.
## Sleep for that period of time.
## On awakening and after verifying the correct time, execute the task at the head of the queue (in background) with the privileges of the user who created it.
## Determine the next time in the future to run this command and place it back on the event list at that time value.

Additionally, the daemon responds to [[SIGHUP]] signals to rescan modified crontab files and schedules special "wake up events" on the hour and half-hour to look for modified crontab files. Much detail is omitted here concerning the inaccuracies of computer time-of-day tracking, Unix alarm scheduling, explicit time-of-day changes, and process management, all of which account for the majority of the lines of code in this cron. This cron also captured the output of ''stdout'' and ''stderr'' and e-mailed any output to the crontab owner.

The resources consumed by this cron scale only with the amount of work it is given and do not inherently increase over time, with the exception of periodically checking for changes.

Williamson completed his studies and departed the University with a Masters of Science in Computer Science and joined AT&T Bell Labs in Murray Hill, New Jersey, and took this cron with him. At Bell Labs, he and others incorporated the [[at (command)|Unix <code>at</code> command]] into cron, moved the crontab files out of users' home directories (which were not host-specific) and into a common host-specific spool directory, and of necessity added the <code>crontab</code> command to allow users to copy their crontabs to that spool directory.

This version of cron later appeared largely unchanged in [[Unix System V]] and in BSD and their derivatives, [[Solaris (operating system)|Solaris]] from [[Sun Microsystems]], [[IRIX]] from [[Silicon Graphics]], [[HP-UX]] from [[Hewlett-Packard]], and [[IBM AIX|AIX]] from [[IBM]]. Technically, the original license for these implementations should be with the Purdue Research Foundation who funded the work, but this took place at a time when little concern was given to such matters.

=== Modern versions ===
With the advent of the [[GNU Project]] and [[Linux]], new crons appeared. The most prevalent of these is the Vixie cron, originally coded by [[Paul Vixie]] in 1987. Version 3 of '''Vixie cron''' was released in late 1993. Version 4.1 was renamed to '''[[Internet Systems Consortium|ISC]] Cron''' and was released in January 2004. Version 3, with some minor bugfixes, is used in most distributions of Linux and BSDs.

In 2007, [[Red Hat]] forked vixie-cron 4.1 to the [[cronie]] project, adding features such as PAM and SELinux support.<ref>{{cite web |title=cronie-crond/cronie |url=https://github.com/cronie-crond/cronie?tab=readme-ov-file |publisher=cronie-crond |date=20 September 2024}}</ref> In 2009, [[anacron]] 2.3 was merged into cronie.<ref>{{cite web |title=Initial upload of anacron-2.3 which should be optimized for better · cronie-crond/cronie@55f4057 |url=https://github.com/cronie-crond/cronie/commit/55f40574a94185a73df8043c4f71f016703c1009 |website=GitHub |language=en}}</ref> Anacron is not an independent cron program however; another cron job must call it. 

[[DragonFly BSD|DragonFly]]'s dcron was made by its founder [[Matthew Dillon (computer scientist)|Matt Dillon]], and its maintainership was taken over by Jim Pryor in 2010.<ref>{{cite mailing list|url=https://mailman.archlinux.org/pipermail/arch-general/2010-January/009981.html |mailing-list=arch-general@archlinux.org |title=Cron  |date=2010-01-05 |access-date=2013-11-06 |first=Jim |last=Pryor}}</ref>

In 2003, Dale Mellor introduced mcron,<ref>{{cite web|url=https://www.gnu.org/software/mcron/design.html |title=Mcron - User Requirements and Analysis |first=Dale |last=Mellor |date=2003-06-01 |access-date=2019-06-11}}</ref> a cron variant written in [[GNU Guile#Guile Scheme|Guile]] which provides cross-compatibility with Vixie cron while also providing greater flexibility as it allows arbitrary [[Scheme (programming language)|scheme]] code to be used in scheduling calculations and job definitions. Since both the mcron daemon and the crontab files are usually written in scheme (though mcron also accepts traditional Vixie crontabs), the cumulative [[State (computer science)|state]] of a user's job queue is available to their job code, which may be scheduled to run [[iff]] the results of other jobs meet certain criteria. Mcron is deployed by default under the [[Guix]] package manager, which includes provisions ([[GNU_Guix#Init_system|services]]) for the package manager to [[Monad_(functional_programming)|monadically]] emit mcron crontabs while both ensuring that packages needed for job execution are installed and that the corresponding crontabs correctly refer to them.<ref>{{cite web|url=https://www.gnu.org/software/guix/manual/en/html_node/Scheduled-Job-Execution.html#Scheduled-Job-Execution |title=GNU Guix Reference Manual: 8.8.2 Scheduled Job Execution |publisher=GNU Guix |date=2019-05-19 |access-date=2019-06-11}}</ref>

A [[webcron|webcron solution]] schedules ring tasks to run on a regular basis wherever cron implementations are not available in a [[web hosting service|web hosting]] environment.