
Cron best practices - leejo
https://sanctum.geek.nz/arabesque/cron-best-practices/
======
euske
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.

~~~
ing33k
I did the "crontab -r" accidentally today . luckily I had a backup.

~~~
slaman
'luckily' \- that's the strangest spelling of 'sanely' I've seen yet.

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

~~~
a3_nm
There's also "chronic" in Moreutils
[https://joeyh.name/code/moreutils/](https://joeyh.name/code/moreutils/) which
seems to serve a similar purpose.

------
makecheck
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
Interesting, newbie question: where do you put the x.crontab file and how do
you get the system to run it? Thanks

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

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

~~~
upofadown
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
It depends how frequently you use a server OS that isn't UNIX. SmartOS and
OpenBSD are great, but they're not popular.

~~~
nailer
I mean _isn 't Linux_, obviously.

------
fideloper
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-t...](http://stackoverflow.com/questions/2135478/how-to-simulate-the-
environment-cron-executes-a-script-with)

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.

------
kchoudhu
Cron best practices: use anything else.

