How to “see” your automated cron jobs | Hacker News Reader

How to “see” your automated cron jobs

gelform.com

9 pointscoreymaass12 comments

I'm not sure what curl is doing here. I set the variable

MAILTO=me@example.com

in my crontab and the stdout/stderr are emailed to me everyday.

from man cron (FreeBSD 8.2)

"When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists)."

Exactly, this is what I do. His solutions seems like a bit too much duct tape and not enough RTFM ;)

Hey, you gotta know the rules to break them. :-) I'd rather have more control than rely on the mailto.

I've found the output of that unreliable, and also I like having control over the output - email or log. Another neat trick is putting counters before and after the CURL call, so I can time how long a script takes.

> I've found the output of that unreliable

Cron is pretty solid software that has not changed much the last decade. If your Cron is unreliable at sending email, there's something unreliable about your setup, basically.

> having control over the output - email or log

Just have Cron pipe the output to a log file, and then cat the file if the script fails with a non-zero exit code:

(/usr/bin/myscript >/tmp/somelog 2>&1 || cat /tmp/somelog)

> Another neat trick is putting counters before and after the CURL call

Just run the script with "time":

((time /usr/bin/myscript) >/tmp/somelog 2>&1 || cat /tmp/somelog)

Your solution of using Curl to run a PHP command is a bit silly because it relies on a web server to do something that does not need involve a web server. It's complicated and failure-prone: if the web server is down, your scripts won't run, and if the web server overloads or is restarted during script execution, the script will probably be killed, or at best will continue to run after Curl finishes up.

At a systems-architectural level it also breaks separation of concerns.

Great all-around reasoning and counter arguments. Now this is HN.

Another tip for automated cronjobs is if a job is going to go over the time (IE: if you have it running every hour and it might run over an hour) use a file lock to make sure they won't run at the same time.

Oh, that's a great suggestion!

Yep. I use the flock tool (comes with most Linux distros, I assume) for this:

flock -nx /var/run/myscript.lock /usr/bin/myscript

This will run the script while keeping a lock. If there is a lock, it will quit immediately.

To paraphrase Babbage:

I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a blog post.

Quick wrapper for the programs that won't shut up when everything is going ok:

https://raw.github.com/sneak/misc/master/cronify/cronify

and to think I spent all this time >/dev/null 2>&1

Reply on news.ycombinator.com