Talk:1728: Cron Mail

I think the "MAILTO" variable in "/etc/crontab" is meant, so only only cron-mails would go to this address, not all mails for the user

Rincewind (talk) 13:09, 2 September 2016 (UTC)

The huge question is whether adding an email message to crontab would result in cron producing even more mail - or whether it would cause cron to fail in some way. The latter would do damage by killing some (possibly critical) cron tasks - the former could rapidly fill up the hard drive with an exponentially-growing crontab. An intermediate situation would be that cron simply ignores the junk and continues to function as before - in which case Cueball's change will have little practical impact on disk space consumption - but probably gradually slow cron's crontab parser to a crawl, which would also have rather severe effects. On most Linux setups, the mail directories are on a different partition to /etc. There is often very little spare space on the partition with /etc on it - so it's likely that Cueball's change will eventually do terrible damage in that case too. 162.158.69.98 14:42, 2 September 2016 (UTC)

On my Mint/Ubuntu/Debian-based Linux system, adding junk to /etc/crontab put a message is /var/log/syslog about "cron[1495]: (*system*) ERROR (Syntax error, this crontab file will be ignored)". So it looks like appending garbage to the crontab will just break cron entirely (or at least those handled by /etc/crontab; it may be private cron and /etc/cron.d/* jobs may continue to run, but cron.hourly, cron.daily, and cron.weekly jobs on my system are initiated through /etc/crontab so they would not run with a broken /etc/crontab). I don't know if other non-Debian distributions have a cron that behaves differently, however. -boB (talk) 15:18, 2 September 2016 (UTC)

Seems like it wouldn't break the existing stuff, they'd still get run and then cron would start parsing the noise and complaining - the "intermediate" situation, though the "export MAILTO" seems wrong. If Cueball did it in his .bashrc, it might get into some of *his* cron jobs but unless it's in /etc/crontab (and there, no "export" is needed/used), it wouldn't matter. His jobs probably wouldn't have rights to write to /etc/crontab either. 173.245.48.73 17:09, 2 September 2016 (UTC)

The current explanation misses a part of the joke present in Cueball's last statement: he is considering the cron program to be somehow sentient and able to make a decision between sending the email (is it really important?) and its self-preservation by not trashing its own config file. He is thus daring cron to continue sending emails at the risk of 'self-destruction'.

- I also feel like the part of the joke is the cron has been sending him useless mail for 15 years. So now, he is sending cron useless mail

This states it can be run as infrequently as once a year, however by using February 29th, you can have it run once every 4 years (exc ever 100 inc every 400). But I think you might be able to get better by also setting it to run on a day of the week. e.g. February 29th, which is a Monday, which would then (after this year) not run for another 28 years, next running on February 29th, 2044.

Should that be noted in the article or is it a needless complication? (Also, I don't know what day of the week is what for this syntax).108.162.250.156 21:13, 2 September 2016 (UTC)