4 ms·

How to “see” your automated cron jobs

9 points by coreymaass 15y ago

TheHunter 15y ago
and to think I spent all this time >/dev/null 2>&1
dazzawazza 15y ago
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)."
- covati 15y ago
  Exactly, this is what I do. His solutions seems like a bit too much duct tape and not enough RTFM ;)
  - coreymaass 15y ago
    Hey, you gotta know the rules to break them. :-) I'd rather have more control than rely on the mailto.
- coreymaass 15y ago
  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.
  - lobster_johnson 15y ago
    > 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.
    - syaz1 15y ago
      Great all-around reasoning and counter arguments. Now this is HN.
sneak 15y ago
Quick wrapper for the programs that won't shut up when everything is going ok: https://raw.github.com/sneak/misc/master/cronify/cronify https://raw.github.com/sneak/misc/master/cronify/cronify
rick888 15y ago
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.
- coreymaass 15y ago
  Oh, that's a great suggestion!
- lobster_johnson 15y ago
  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.
zwischenzug 15y ago
To paraphrase Babbage: I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a blog post.

9 points by coreymaass 15y ago

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

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

covati 15y ago
Exactly, this is what I do. His solutions seems like a bit too much duct tape and not enough RTFM ;)
- coreymaass 15y ago
  Hey, you gotta know the rules to break them. :-) I'd rather have more control than rely on the mailto.
coreymaass 15y ago
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.
- lobster_johnson 15y ago
  > 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.
  - syaz1 15y ago
    Great all-around reasoning and counter arguments. Now this is HN.

sneak 15y ago

Quick wrapper for the programs that won't shut up when everything is going ok: https://raw.github.com/sneak/misc/master/cronify/cronify https://raw.github.com/sneak/misc/master/cronify/cronify

rick888 15y ago

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.

coreymaass 15y ago
Oh, that's a great suggestion!
lobster_johnson 15y ago
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.

zwischenzug 15y ago

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