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

1 Answer 1


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.
  • 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, 2014 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, 2014 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. Jun 2, 2014 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
    – user591
    Jun 3, 2014 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. Jun 3, 2014 at 16:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .