Difference between revisions of "Talk:1728: Cron Mail"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
Line 5: Line 5:
  
 
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.
+
: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)

Revision as of 15:18, 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)