5 ms·

Cron best practices

97 points by leejo 10y ago

euske 10y ago
The crontab command has one of the worst UI problems: 1. "crontab -e" lets you edit your crontab file, and "crontab -r" deletes it (without asking). The two keys are next to each other. 2. "crontab" (no arg) reads the contents of the crontab file from stdin and replaces it. When you accidentally hit Ctrl-D after it, your crontab is replaced with an empty file.
- yeowMeng 10y ago
  man pages could use a new section that literally contains @euske comment. The new section should be called: 'Gotcha'.
- ing33k 10y ago
  I did the "crontab -r" accidentally today . luckily I had a backup.
  - slaman 10y ago
    'luckily' - that's the strangest spelling of 'sanely' I've seen yet.
Ao7bei3s 10y ago
0. Use systemd timers instead. OnCalendar= has a less insane format than cron, exit code and output logging, locking, proper command line tools, and other niceties like Persistent= (catch up e.g. after system was powered off) etc. (And yes, you can still have user "cronjobs" if you enable systemd user session lingering.)
- jle17 10y ago
  Having to create two files for a single task must get old fast though.
  - vertex-four 10y ago
    Which is why higher-level tools for system administration are awesome. NixOS will generate the .timer and .service files from two options sitting next to each other in a single file (script and startOn) - and you can put them right next to your application service definition and web server configuration. I assume there's systemd unit generators for Ansible, Puppet, etc etc too.
- upofadown 10y ago
  There are lots of ways of scheduling stuff out there. The systemd stuff is Linux only, so there isn't really any good reason to bother to learn it for trivial stuff like timed jobs. Cron is much the same everywhere.
  - nailer 10y ago
    It depends how frequently you use a server OS that isn't UNIX. SmartOS and OpenBSD are great, but they're not popular.
    - nailer 10y ago
      I mean isn't Linux, obviously.
quentindemetz 10y ago
Cronic (http://habilis.net/cronic/ http://habilis.net/cronic/) has been a real life-saver when it comes to using cron in production services. I've been using it for 4+ years without looking back.
- _nato_ 10y ago
  In the same-ish vein, may I suggest http://ikura.co http://ikura.co for anyone wishing to link timely jobs w/ their web applications.
- a3_nm 10y ago
  There's also "chronic" in Moreutils https://joeyh.name/code/moreutils/ https://joeyh.name/code/moreutils/ which seems to serve a similar purpose.
kchoudhu 10y ago
Cron best practices: use anything else.
makecheck 10y ago
I never edit a crontab directly. I use external files and reinstall them with "crontab filename" as needed. Then of course the files can be revision-controlled. Also, I name the files according to host so I remember exactly where they were installed in a networked environment (e.g. "host1.crontab", "host2.crontab").
- supster 10y ago
  Interesting, newbie question: where do you put the x.crontab file and how do you get the system to run it? Thanks
  - thevibesman 10y ago
    x.crontab can live wherever you'd like; you can even delete it after you install the crontab. When you run the following command crontab x.crontab your crontab file is replaced by the contents of x.contrab; or if you want to install x.crontab for another user crontab -u www-user x.crontab The actual location of x.crontab does not matter as it is just used to setup your cron jobs, but the system does not actually read from this file to run the jobs.
  - harshreality 10y ago
    I put per-user crontab stuff in ~/.cron/ not only cron-specific scripts go there, but ~/.cron/crontab is the (inactive) master copy of the crontab itself. Make changes active with `crontab ~/.cron/crontab` Diff with `diff -du <(crontab -l) <(cat ~/.cron/crontab)` For servers or not-my-own-user crontabs, config management is the way to go. The crontabs should be in a config management repository, so there's not just a single copy that's deployed and active.
fideloper 10y ago
A few notes that I think are worth going over: 1. mysqldump can require quite a few more permissions than mentioned, depending on your utilization of mysql 2. The best way I've found to test the cron-like environmentis by following this: http://stackoverflow.com/questions/2135478/how-to-simulate-the-environment-cron-executes-a-script-with http://stackoverflow.com/questions/2135478/how-to-simulate-t... Otherwise you run the risk of .profile (and similar) being loaded, where they will not be when run in the cron task. 3. Extra emphasis on using a lock file to avoid overlapping cron tasks! 4. I love using `time` or similar means to pass execution time somewhere (a log file, or a web hook), which helps with point 3.

97 points by leejo 10y ago

euske 10y ago

The crontab command has one of the worst UI problems: 1. "crontab -e" lets you edit your crontab file, and "crontab -r" deletes it (without asking). The two keys are next to each other. 2. "crontab" (no arg) reads the contents of the crontab file from stdin and replaces it. When you accidentally hit Ctrl-D after it, your crontab is replaced with an empty file.

yeowMeng 10y ago
man pages could use a new section that literally contains @euske comment. The new section should be called: 'Gotcha'.
ing33k 10y ago
I did the "crontab -r" accidentally today . luckily I had a backup.
- slaman 10y ago
  'luckily' - that's the strangest spelling of 'sanely' I've seen yet.

Ao7bei3s 10y ago

0. Use systemd timers instead. OnCalendar= has a less insane format than cron, exit code and output logging, locking, proper command line tools, and other niceties like Persistent= (catch up e.g. after system was powered off) etc. (And yes, you can still have user "cronjobs" if you enable systemd user session lingering.)

jle17 10y ago
Having to create two files for a single task must get old fast though.
- vertex-four 10y ago
  Which is why higher-level tools for system administration are awesome. NixOS will generate the .timer and .service files from two options sitting next to each other in a single file (script and startOn) - and you can put them right next to your application service definition and web server configuration. I assume there's systemd unit generators for Ansible, Puppet, etc etc too.
upofadown 10y ago
There are lots of ways of scheduling stuff out there. The systemd stuff is Linux only, so there isn't really any good reason to bother to learn it for trivial stuff like timed jobs. Cron is much the same everywhere.
- nailer 10y ago
  It depends how frequently you use a server OS that isn't UNIX. SmartOS and OpenBSD are great, but they're not popular.
  - nailer 10y ago
    I mean isn't Linux, obviously.

quentindemetz 10y ago

Cronic (http://habilis.net/cronic/ http://habilis.net/cronic/) has been a real life-saver when it comes to using cron in production services. I've been using it for 4+ years without looking back.

_nato_ 10y ago
In the same-ish vein, may I suggest http://ikura.co http://ikura.co for anyone wishing to link timely jobs w/ their web applications.
a3_nm 10y ago
There's also "chronic" in Moreutils https://joeyh.name/code/moreutils/ https://joeyh.name/code/moreutils/ which seems to serve a similar purpose.

kchoudhu 10y ago

Cron best practices: use anything else.

makecheck 10y ago

I never edit a crontab directly. I use external files and reinstall them with "crontab filename" as needed. Then of course the files can be revision-controlled. Also, I name the files according to host so I remember exactly where they were installed in a networked environment (e.g. "host1.crontab", "host2.crontab").

supster 10y ago
Interesting, newbie question: where do you put the x.crontab file and how do you get the system to run it? Thanks
- thevibesman 10y ago
  x.crontab can live wherever you'd like; you can even delete it after you install the crontab. When you run the following command crontab x.crontab your crontab file is replaced by the contents of x.contrab; or if you want to install x.crontab for another user crontab -u www-user x.crontab The actual location of x.crontab does not matter as it is just used to setup your cron jobs, but the system does not actually read from this file to run the jobs.
- harshreality 10y ago
  I put per-user crontab stuff in ~/.cron/ not only cron-specific scripts go there, but ~/.cron/crontab is the (inactive) master copy of the crontab itself. Make changes active with `crontab ~/.cron/crontab` Diff with `diff -du <(crontab -l) <(cat ~/.cron/crontab)` For servers or not-my-own-user crontabs, config management is the way to go. The crontabs should be in a config management repository, so there's not just a single copy that's deployed and active.

fideloper 10y ago

A few notes that I think are worth going over: 1. mysqldump can require quite a few more permissions than mentioned, depending on your utilization of mysql 2. The best way I've found to test the cron-like environmentis by following this: http://stackoverflow.com/questions/2135478/how-to-simulate-the-environment-cron-executes-a-script-with http://stackoverflow.com/questions/2135478/how-to-simulate-t... Otherwise you run the risk of .profile (and similar) being loaded, where they will not be when run in the cron task. 3. Extra emphasis on using a lock file to avoid overlapping cron tasks! 4. I love using `time` or similar means to pass execution time somewhere (a log file, or a web hook), which helps with point 3.