1728: Cron Mail - Revision history

Jacky720: rv

2022-05-04T21:11:21Z

Show changes

Ex Kay Cee Dee at 17:24, 4 May 2022

2022-05-04T17:24:32Z

Show changes

Wafflefly21: Undo revision 237214 by X. K. C. D. (talk)

2022-05-04T01:35:25Z

Undo revision 237214 by X. K. C. D. (talk)

Show changes

X. K. C. D. at 01:31, 4 May 2022

2022-05-04T01:31:33Z

Show changes

172.70.162.147: Better solution for a direct quote?

2022-01-01T22:43:13Z

Better solution for a direct quote?

162.158.102.61: /* Explanation */

2022-01-01T20:56:19Z

‎Explanation

Jimbob: /* Explanation */

2016-09-06T18:55:55Z

‎Explanation

Jimbob: /* Explanation */ fix backticks markdown notation to `.`


2016-09-06T18:54:40Z
‎Explanation:   fix backticks markdown notation to <code>.

				
				
				
				
				
				← Older revision
				Revision as of 18:54, 6 September 2016
				
Line 14:
Line 14:
  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 your 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 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 your 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 `MAILTO` 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 `/etc/crontab`.  Thus when cron attempts to email `/etc/crontab` the mail program cron uses will generate an error saying it can't find the user `/etc/crontab`.   + 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>.  
    
  For example, if you create the following crontab:   For example, if you create the following crontab:



Jimbob: /* Explanation */
2016-09-06T18:51:44Z
‎Explanation

				
				
				
				
				
				← Older revision
				Revision as of 18:51, 6 September 2016
				
Line 14:
Line 14:
  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 your 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 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 your 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 most likely break cron entirely, as the text output from the cron jobs is unlikely to be in the same format as a valid schedule entry in the crontab file.  Invalid scheduling information will cause cron to ignore the file - this will then cause it to have no scheduled jobs at all, and it will simply do nothing after the first job that sends itself an email.  Cueball will, in fact, have stopped the tide of cron spam, but will likely cause bigger problems due to the sudden lack of critical system maintenance tasks. + In reality, this will not cause significant problems as the `MAILTO` 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 `/etc/crontab`.  Thus when cron attempts to email `/etc/crontab` the mail program cron uses will generate an error saying it can't find the user `/etc/crontab`. 
  +  
  + For example, if you create the following crontab:
  +  
  + <pre>
  + MAILTO=/etc/crontab
  +  
  + * * * * * echo "Some output from a cronjob"
  + </pre>
  +  
  + installed on a user named `me` on a system called `mycomputer` then you will see a new error messages email to you (located in `/var/mail/me`) stating it can't send email to a user named `/etc/crontab` and the undelivered email is being returned to the sender.  The error email will look like the following: 
  +  
  + <pre>
  + From MAILER-DAEMON  Tue Sep  6 14:47:01 2016
  + Return-Path: <>
  + X-Original-To: me@mycomputer.local
  + Delivered-To: me@mycomputer.local
  + Received: by mycomputer.local (Postfix)
  +         id 5341C64EE516; Tue,  6 Sep 2016 14:47:01 -0400 (EDT)
  + Date: Tue,  6 Sep 2016 14:47:01 -0400 (EDT)
  + From: MAILER-DAEMON@mycomputer.local (Mail Delivery System)
  + Subject: Undelivered Mail Returned to Sender
  + To: me@mycomputer.local
  + Auto-Submitted: auto-replied
  + MIME-Version: 1.0
  + Content-Type: multipart/report; report-type=delivery-status;
  +         boundary="33AF864EE514.1473187621/mycomputer.local"
  + Message-Id: <20160906184701.5341C64EE516@mycomputer.local>
  +  
  + This is a MIME-encapsulated message.
  +  
  + --33AF864EE514.1473187621/mycomputer.local
  + Content-Description: Notification
  + Content-Type: text/plain; charset=us-ascii
  +  
  + This is the mail system at host mycomputer.local.
  +  
  + I'm sorry to have to inform you that your message could not
  + be delivered to one or more recipients. It's attached below.
  +  
  + For further assistance, please send mail to postmaster.
  +  
  + If you do so, please include this problem report. You can
  + delete your own text from the attached returned message.
  +  
  +                    The mail system
  +  
  + </etc/crontab@mycomputer.local> (expanded from </etc/crontab>): unknown user:
  +     "/etc/crontab"
  +  
  + --33AF864EE514.1473187621/mycomputer.local
  + Content-Description: Delivery report
  + Content-Type: message/delivery-status
  +  
  + Reporting-MTA: dns; mycomputer.local
  + X-Postfix-Queue-ID: 33AF864EE514
  + X-Postfix-Sender: rfc822; me@mycomputer.local
  + Arrival-Date: Tue,  6 Sep 2016 14:47:00 -0400 (EDT)
  +  
  + Final-Recipient: rfc822; /etc/crontab@mycomputer.local
  + Original-Recipient: rfc822; /etc/crontab
  + Action: failed
  + Status: 5.1.1
  + Diagnostic-Code: X-Postfix; unknown user: "/etc/crontab"
  +  
  + --33AF864EE514.1473187621/mycomputer.local
  + Content-Description: Undelivered Message
  + Content-Type: message/rfc822
  +  
  + Return-Path: <me@mycomputer.local>
  + Received: by mycomputer.local (Postfix, from userid 501)
  +         id 33AF864EE514; Tue,  6 Sep 2016 14:47:00 -0400 (EDT)
  + From: me@mycomputer.local (Cron Daemon)
  + To: /etc/crontab@mycomputer.local
  + Subject: Cron <me@mycomputer> echo "Some output from a cronjob"
  + X-Cron-Env: <MAILTO=/etc/crontab>
  + X-Cron-Env: <SHELL=/bin/sh>
  + X-Cron-Env: <PATH=/usr/bin:/bin>
  + X-Cron-Env: <LOGNAME=me>
  + X-Cron-Env: <USER=me>
  + X-Cron-Env: <HOME=/Users/me>
  + Message-Id: <20160906184701.33AF864EE514@mycomputer.local>
  + Date: Tue,  6 Sep 2016 14:47:00 -0400 (EDT)
  +  
  + Some output from a cronjob
  +  
  + --33AF864EE514.1473187621/mycomputer.local--
  + </pre>
  +  
    
  The title text shows that Cueball is somewhat aware of what cron does, including the fact that it's existed pretty much unchanged for several decades, but he hasn't bothered to really get into understanding it, treating it more as a foe to vanquish rather than as a tool to understand and use.   The title text shows that Cueball is somewhat aware of what cron does, including the fact that it's existed pretty much unchanged for several decades, but he hasn't bothered to really get into understanding it, treating it more as a foe to vanquish rather than as a tool to understand and use.



162.158.83.132: /* Explanation */ typo
2016-09-05T15:34:15Z
‎Explanation:  typo

				
				
				
				
				
				← Older revision
				Revision as of 15:34, 5 September 2016
				
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 suggests that Cueball "fix your 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 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 your 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 most likely break cron entirely, as the text output from the cron jobs is unlikely to be in the same format as a valid schedule entry in the crontab file.  Invalid scheduling information will cause cron to ignore the file - this will then cause it to have no scheduled jobs at all, and it will simply do nothing after the first job that sends itself an email.  Cueball will, in fact, have stopped the tide of cron spam, but will likely cause bigger problems due to the sudden lack of critical system maintenance tasks.   In reality, this will most likely break cron entirely, as the text output from the cron jobs is unlikely to be in the same format as a valid schedule entry in the crontab file.  Invalid scheduling information will cause cron to ignore the file - this will then cause it to have no scheduled jobs at all, and it will simply do nothing after the first job that sends itself an email.  Cueball will, in fact, have stopped the tide of cron spam, but will likely cause bigger problems due to the sudden lack of critical system maintenance tasks.

@@ 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.
-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 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 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>.

@@ Line 24: / Line 24: @@
 </pre>
-installed on a user named `me` on a system called `mycomputer` then you will see a new error messages email to you (located in `/var/mail/me`) stating it can't send email to a user named `/etc/crontab` and the undelivered email is being returned to the sender.  The error email will look like the following:
+installed on a user named <code>me</code> on a system called <code>mycomputer</code> then you will see a new error messages email to you (located in <code>/var/mail/me</code>) stating it can't send email to a user named <code>/etc/crontab</code> and the undelivered email is being returned to the sender.  The error email will look like the following:
 <pre>

1728: Cron Mail - Revision history

Jacky720: rv

Ex Kay Cee Dee at 17:24, 4 May 2022

Wafflefly21: Undo revision 237214 by X. K. C. D. (talk)

X. K. C. D. at 01:31, 4 May 2022

172.70.162.147: Better solution for a direct quote?

162.158.102.61: /* Explanation */

Jimbob: /* Explanation */

Jimbob: /* Explanation */ fix backticks markdown notation to .

Jimbob: /* Explanation */

162.158.83.132: /* Explanation */ typo

Jimbob: /* Explanation */ fix backticks markdown notation to `.`