4 ms·

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

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.

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.