7

The /etc/crontab file on ubuntu has a header that reads:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

What are the other crontabs this mentions? The text has been there as long as I've been using Ubuntu so I don't know what any alternatives are (or were).
Googling the phrase didn't seem to have any useful results either. I was able to find it in a svagner/vixie-cron repo, but not in the vixie/cron repo so I wasn't sure where to go for more info.

5
  • 3
    Quite likely, the original Unix crontab, which I think appeared in version 7. But this is Open Sores software, so anyone can write their own version of anything. The wikipedia page may give you some clues as to where to look. Jul 19 at 22:09
  • 11
    Per-user crontabs? Jul 19 at 22:15
  • 6
    This question may be better suited for the Unix & Linux site Jul 20 at 14:28
  • Don't tell me that just because Poeterring came along and invented .timers that cron is now "retro". kids these days!
    – Billy C.
    Jul 20 at 19:07
  • 2
    @BillyC. I misunderstood the text! I thought it was referring to some disused alternative that died off in the 90s, not per-user crontabs. It probably should be migrated to Unix SA
    – GammaGames
    Jul 20 at 19:34
30

As far as I can tell, the phrase "other crontabs" refers not to other versions of cron, but to the per-user crontabs. The description of the differences certainly fits with the differences between user crontabs and the system crontab.

The passage of text itself is not part of the upstream cron source but is part of the Debian packaging of cron. The oldest version of Debian for which sources are available on archive.debian.org is 0.93R6. I looked in http://archive.debian.org/debian/dists/Debian-0.93R6/source/admin/cron-3.0pl1-20.diff.gz and found a template file very similar to the one used today.

--- cron-3.0pl1.orig/debian.add/crontab Thu Jan  1 01:00:00 1970
+++ cron-3.0pl1/debian.add/crontab  Wed Sep 21 10:43:21 1994
@@ -0,0 +1,12 @@
+# /etc/crontab: system-wide crontab
+# Unlike any other crontab you don't have to run the `crontab'
+# command to install the new version when you edit this file.
+# This file also has a username field, that none of the other crontabs do.
+
+SHELL=/bin/sh
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+
+# m h dom mon dow user command
+42 6   * * *   root    run-parts /etc/cron.daily
+47 6   * * 7   root    run-parts /etc/cron.weekly
+52 6   1 * *   root    run-parts /etc/cron.monthly

I have no idea if the comment was written by someone packaging cron for Debian or if they copied it from somewhere else.

2
  • 1
    Oh, that's an interesting interpretation. I think you might be on to something. The crontab(1) page hints at that -- it looks like the user's crontab needs to be copied into a spool directory by the crontab(1) command. Jul 19 at 23:11
  • That's what I've always understood it to mean. Jul 20 at 9:29
3

[Erm, I'm not really sure if that question is serious. Or does the OP really believe the crontab implementation used in Unbuntu is the only one there is and ever has been?]

Crontab is a data file for cron, a program like any other in unix or unixoide systems, implemented many times and in many ways.

At that point it might be important to keep in mind that things like program notifications if files have been changed and alike OS services are a rather new developmen.t

The original (Unix V7) cron implementation followed a very simple course of action:

  • Read /usr/lib/crontab
  • Determine if any job had to be started
    • if yes, start that command
  • Sleep for one minute
  • Rinse and repeat

This is a rather robust approach. It didn't matter much if the crontab file got changed between two cycles (within a minute), as it was reread anyway. Problem is that this procedure is rather resource hungry. The file needs to be reread every minute, no matter if changed or not, it needed to be read every minute, no matter if there is a job scheduled or not.

With machines as small as back then these activities were already a nuisance, so people tried to optimize by changing the sequence:

  • Read /usr/lib/crontab
  • Determine if any job had to be started
    • if yes, start that command
  • Calculate how long until the next job to be started
  • Sleep for as long as calculated

This reduced system load quite remarkably, cron load now scaled only linear with the number of jobs to be started. On the back side, any change to crontab was only recognized when the next scheduled event was to come. So when the change introduced a new jobstart before the last next to do, it was not executed - unless cron got killed and restarted.

This improvement came in especially handy as System V introduced per user crontab handling, as now dozends to hundreds of files had to be handled. W. Franta and Kurt Maly, who implemented the new cron, made it read all files and build an event list with an entry per file during startup. Like before cron went into sleep until the next event in that list was to be executed.

But unlike the previous step, they went full optimization and included not just the next event, but all for up to an hour. At the end of the list (he hour) an internal entry was inserted so schedule reread of all crontab files. Quite a great improvement - but re-synchronisation with changed file(s) would not happen for a long time.

To handle this they made cron react to SIGHUP, so a cron could be forced to reread all files with a simple kill -HUP.

This was ca. 1983. When again later the crontab files were moved from user home directories into a central spool directory, the crontab command referenced in above comment got introduced (~1986). It allowed a user to move his crontab file into that system directory and did send cron a message to reread all files.

This is the level next to all Unix derivatives from AIX to BSD copied.

Since then quite a lot different cron implementations have been made, most notably Vixie-cron, which IIRC was the base for cron used in various Linux distributions. Over the years it got a lot of improvements, like being informed of changes within the spool directory to enable automatic update.

Which cron is used in your system and how it works in detail is something you might have to lookup on your own.

5
  • I believe reading the file every minute also scales linearly; it's just slower and may have a comparatively large time-constant part because of the context switches and meta data I/O that are independent of the number of jobs. Jul 20 at 6:39
  • @Peter-ReinstateMonica True if only comparing the original version (reading every minute without any optimizaion) vs. Franta/Maly (reading every hour and keeping multiple events in memory). But the remark about linear isn't about that, but the version with variable timer but no event list in memory.
    – Raffzahn
    Jul 20 at 11:32
  • Well, whatever it refers to: All implementations appear to behave linear with the number of jobs. I think it would be hard to do better, and not obvious how to do worse. Jul 20 at 11:49
  • @Peter-ReinstateMonica The resources needed to start jobs are the same for all implementations, there is no implementation dependent scaling. Implementation dependence comes only from the way these jobs are managed. V7 implementation did not scale much at all. It did 1440 full reads of the single crontab per day. Improved handling reduced that to number of jobs reads to number of events with a ceiling of 1440 (and that is the scaling by events), while SV does 24 reads per day per crontab, so again pretty static load. File reading is the major variable resource usage for cron.
    – Raffzahn
    Jul 20 at 12:00
  • 1
    This is a nice history, thank you for writing it!
    – GammaGames
    Jul 20 at 19:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.