Difference between revisions of "Talk:1728: Cron Mail"
Line 6: | Line 6: | ||
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. [[Special:Contributions/162.158.69.98|162.158.69.98]] 14:42, 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. [[Special:Contributions/162.158.69.98|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. [[User:N0lqu|-boB]] ([[User talk:N0lqu|talk]]) 15:18, 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. [[User:N0lqu|-boB]] ([[User talk:N0lqu|talk]]) 15:18, 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'. |
Revision as of 15:43, 2 September 2016
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)
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'.