37

I'm curious to know: why are crontabs stored in /var rather than in the user's home directories? It makes it a total pain to isolate these files for upgrades but I suspect that there is a logical reason...

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Martin Eve
  • 655
  • 1
  • 6
  • 12

1 Answers1

42

Few reasons I can think of:

  • In corporate environments, you can have thousands of users. If so, cron would have to scan through every single user's directory every single minute to check for the crontab file (whether it has been created, deleted, or modified).
    By keeping them in a single location, it doesn't have to do this intensive scan.
  • Home directories might not be always available. If the home directories are an autofs mount, they might not be mounted. Having cron check them every single minute would cause them to be mounted, and prevent them from unmounting due to inactivity. Also if the home directory is encrypted, and decrypted with the user's password, cron won't be able to get to the home directory unless the user has logged in and decrypted/mounted it.
  • Home directories might be shared across hosts. If the home directory is a network share, that same home directory will appear on multiple hosts. But you might not want your cron jobs to run on every single host, just one of them.
phemmer
  • 70,657
  • 19
  • 188
  • 223
  • Thanks for the responses; some kindof obvious when I thought about it but didn't strike me at the time -- which was in the middle of realising that I'd just wiped my tabs on an upgrade! – Martin Eve Jun 02 '14 at 12:46
  • 1
    +1 Although traditionally `cron` did not rescan those files every minute; it loaded them once and only re-read them on a signal. – goldilocks Jun 02 '14 at 12:46
  • @goldilocks You sure? How would that even work? A user has permissions to edit their own crontab (`crontab -e`), but `cron` runs as root, so they don't have permission to `SIGHUP` the process. – phemmer Jun 02 '14 at 12:50
  • I don't have such a version (I don't even know if they still exist), but I'd presume that's correct, if you changed your own crontab, it would not be automatically reloaded; you might have to wait. – goldilocks Jun 02 '14 at 12:57
  • 7
    But you are right about point #3; according to [wikipedia](http://en.wikipedia.org/wiki/Cron#History) crontabs *were* originally in $HOME, until "[Bell lab devs] incorporated the Unix at 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..." That's also when the `crontab` command was created which might have dealt with the reloading issue. – goldilocks Jun 02 '14 at 13:01
  • Vixie cron periodically checks the mtime of the user crontab spool directory, and `crontab -e`, which is setuid root, sets the mtime of that directory to the current time when any crontab is modified. – Mark Plotnick Jun 02 '14 at 22:53
  • @MarkPlotnick Directory mtime is only changed when a file is added or removed, not modified. – phemmer Jun 02 '14 at 23:03
  • 2
    @Patrick Or when a program uses the `utimes` system call, with the spool directory path as its argument, to set the directory's mtime, which is what Vixie cron's `crontab` command does. – Mark Plotnick Jun 02 '14 at 23:09
  • 2
    Early versions of cron certainly didn't pick up changes to user crontab files unless they were edited via crontab -e. I have been caught out by this in the past on Solaris see this decades old man page http://www.manpages.info/sunos/cron.1.html –  Jun 03 '14 at 06:41
  • OOh Solaris still only checks when process initialises and crontab is run [cron only examines crontab or at command files during its own process initialization phase and when the crontab or at command is run. This reduces the overhead of checking for new or changed files at regularly scheduled intervals.](http://docs.oracle.com/cd/E26502_01/html/E29031/cron-1m.html) –  Jun 03 '14 at 09:09
  • 2
    On Solaris 10, `crontab -e`, which is setuid root, writes a message to `/etc/cron.d/FIFO` after a user edits a crontab. – Mark Plotnick Jun 03 '14 at 16:48