35

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...

|improve this question
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.
|improve this answer
  • 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 2 '14 at 12:46
  • 7
    But you are right about point #3; according to wikipedia 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 2 '14 at 13:01
  • 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 2 '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 manpages.info/sunos/cron.1.html – Iain Jun 3 '14 at 6:41
  • 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 3 '14 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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