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...
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 '14 at 12:46 -
7But 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'scrontab
command does. – Mark Plotnick Jun 2 '14 at 23:09 -
2Early 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 '14 at 6:41
-
2On 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