Editing 1728: Cron Mail

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 12: Line 12:
 
When a cron job produces output, cron's default behavior is to send an email to the user account under which the job ran.  However, in most situations, an email address has not been set up for that user, so the email is instead written to a mailbox file.  Most Unix shells will notify the user with a message like "You have new mail" when this mailbox file is updated, but if the user doesn't know how to check this mail file, they will likely just ignore the message.
 
When a cron job produces output, cron's default behavior is to send an email to the user account under which the job ran.  However, in most situations, an email address has not been set up for that user, so the email is instead written to a mailbox file.  Most Unix shells will notify the user with a message like "You have new mail" when this mailbox file is updated, but if the user doesn't know how to check this mail file, they will likely just ignore the message.
  
βˆ’
In this case, Cueball has been ignoring his mailbox for fifteen years.  When he finally learns where to look, he discovers more than a gigabyte worth of messages from the cron program, the vast majority of which are likely meaningless.  Ponytail says to Cueball "fix your cron" (likely meaning he should fix the task that's generating the output so that it doesn't do so), then set a parameter that tells cron to send email to an address he actually checks.  (He could also opt to direct the mails to <code>/dev/null</code>, which would discard them, or simply disable the mail in the crontab.)  Cueball, however, interprets the tremendous amount of email as spam and decides to redirect the emails to <code>/etc/crontab</code>, the main configuration file that contains all of cron's scheduling information.  He apparently believes that this will either stop the emails or cause cron to spam itself instead.
+
In this case, Cueball has been ignoring his mailbox for fifteen years.  When he finally learns where to look, he discovers more than a gigabyte worth of messages from the cron program, the vast majority of which are likely meaningless.  Ponytail suggests that Cueball "fix his cron" (likely meaning to fix the task that's generating the output so that it doesn't do so), then set a parameter that tells cron to send email to an address he actually checks.  (He could also opt to direct the mails to <code>/dev/null</code>, which would discard them, or simply disable the mail in the crontab.)  Cueball, however, interprets the tremendous amount of email as spam and decides to redirect the emails to <code>/etc/crontab</code>, the main configuration file that contains all of cron's scheduling information.  He apparently believes that this will either stop the emails or cause cron to spam itself instead.
  
 
In reality, this will not cause significant problems as the <code>MAILTO</code> environmental variable in cron takes an email address or usernames on the local system and attempts to send emails to them.  It will not write or append output to a local file like <code>/etc/crontab</code>.  Thus when cron attempts to email <code>/etc/crontab</code> the mail program cron uses will generate an error saying it can't find the user <code>/etc/crontab</code>.  
 
In reality, this will not cause significant problems as the <code>MAILTO</code> environmental variable in cron takes an email address or usernames on the local system and attempts to send emails to them.  It will not write or append output to a local file like <code>/etc/crontab</code>.  Thus when cron attempts to email <code>/etc/crontab</code> the mail program cron uses will generate an error saying it can't find the user <code>/etc/crontab</code>.  

Please note that all contributions to explain xkcd may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see explain xkcd:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel | Editing help (opens in new window)