Hacker News Reader

Comment by cma | Hacker News Reader

A cron job kicks off that makes the whole system unresponsive, undergoing heavy swap (updatedb used to do this and ran every night on many default systems).

Someone edits a cron file in the most common editor, vim. On many systems it doesn't do an atomic swap on save without extra configuration: http://stackoverflow.com/questions/13563627/how-does-vim-sav...

Now maybe your unresponsive, undergoing swap, system misses a cron job that was present in both edits. Opps.

I'm not sure this could really play out, but the approach definitely sounds firmly on the "worse is better" side of the scale.

View on HN

crontab -e is the way to edit your cron. A similar command exists for editing the sudoers file which is visudo. This will ensure your configuration is a valid syntax as well as do an atomic swap of the file.

Otherwise adding a file or deleting a file in /etc/cron.d/ is the way to go for automatic(ansbile, puppet etc) and package installations.

I'm surprised that people would edit cron in any other way, crontab -e is one of the first commands most intro to Linux manuals teaches.

However crontab -r has to be one of the most poorly thought out commands in UNIX. It removes the cron file and since r is only one character over from e on qwerty keyboards it's a painful and surprising typo.

what if you are managing the crons externally, eg puppet, crontab -e is not always option

1. If you don't have a test process for changes made with puppet, this is hardly a problem with cron.

2. Puppet handled that parsing for you and will throw errors if your syntax is wrong

Use /bin/cat as editor. That should work nicely from Puppet.

I can't tell you the amount of times I've hit -r by mistake and regretted it..

I can. 0. There, more anecdata.

Honestly though, I never use `-e` either. I keep a ~/.crontab and edit that, and then `crontab ~/.crontab`.

Voila, backup/time machine/git friendly crontab.

Have a cronjob that backs up your crontab?

I got bit by this once, and had to rescue the crontab out off the disk with GNU strings :(

first thing when logging into new server: place /etc under git. then loss of cron files (or any config file) is easily recovered from.

This is a brilliant idea - thank you!

I cannot count the number of times this has helped or saved me. You can keep the /etc git repo local. Or if its a critical server, push to github private repo. Seeing a history of your /etc edits is a very reassuring feeling.

Except that crontabs are usually somewhere in /var. :)

Which is why I only use system-wide crontabs, in /etc/cron.d

Instead of per-user crontabs. Much easier to manage.

With cron.d you can specify what user each cron entry should run as, so it is equivalent.

And there's "vipw" for the password file. Each of them with their own separate updating bugs.

"Worse is better" is an oxymoron. You can also read it as "better is worse". In "worse is better", the "worse" isn't really worse in practical settings (considering all tradeoffs, giving appropriate weights to design goals, etc.).

Nobody argues that there can't be problems. What all critics miss is to show how to avoid these problems.

What can you do about jobs that make the system unresponsive? Not a problem for cron to solve.

If someone writes a crontab (instead of rename()ing another version over it), that's not cron's fault. Sqlite databases can be just as easily corrupted or lose integrity. Now which format would you rather repair?

Missing a cron job can not be totally avoided, and it isn't the end of the world. What if your machine goes down or cron crashes? The answer is that the jobs themselves have to be provided with some resilience against that situation.

This isn't a case of "worse is better" since there weren't proposed solutions to the "problems" at all, however unrealistic.

This is a perfect example for why you ought to monitor all your cronjobs with something like https://wdt.io.

Reply on news.ycombinator.com