On Apr 25, 2016, at 11:12 AM, Don Buchholz <buchh...@easystreet.net> wrote: > >> … >> the command `crontab -e` creates a copy of your crontab file in /tmp. >> After you complete your editing and save it the crontab program checks it for >> validity before copying the version in /tmp to the real crontab - in your >> example >> it is probably /var/spool/cron/jjj or /var/spool/cron/crontabs/jjj >> >> No, not in ~/ the folks who created cron decided that all cron files on a >> system >> should be stored in the same place. > > In a true NFS environment, you would almost certainly not want > your crontab kept in $HOME. Consider an network with ~100 work- > stations and a single NFS server providing $HOME for the entire > userbase. When you schedule a task for 3pm, which one of the > 100+ systems should run that job? This is why job scheduling > is managed on a local filesystems (e.g. /var, /etc, …). > Even if you store(d) it in ~/, all the systems I’ve used, require that the user manually tell the system to use a crontab file (regardless of where it is), so theoretically, this would still work. That said, unless you uniquely named them, or provided unique paths to them, its a recipe for bad things to happen in a quasi-automated fashion.
I’m imagining a cron job that is supposed to run every 5m and generates an email, running on hundreds (or thousands if you have a larger environment) of hosts, generating errors on all but 1. Waking up to 10,000 emails all from cron. -- Louis Kowolowski lou...@cryptomonkeys.org <mailto:lou...@cryptomonkeys.org> Cryptomonkeys: http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> Making life more interesting for people since 1977 _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
