explain xkcd - User contributions [en]

1728: Cron Mail

2016-09-04T09:42:35Z

Alphanet: /* spelling */

{{comic
| number = 1728
| date = September 2, 2016
| title = Cron Mail
| image = cron_mail.png
| titletext = Take THAT, piece of 1980s-era infrastructure I've inexplicably maintained on my systems for 15 years despite never really learning how it works.
}}

==Explanation==
{{incomplete|Format information, the bottom two paragraphs should be at the top. Also shorten and simplify explanation.}}
On {{W|Unix}}-like systems, {{W|Cron|cron}} is a system program running in background which allows one to schedule jobs to run at well-defined time slots. It is conceptually the same software which has been used since, at least, the 1980s and is still heavily used in modern operating systems, for example in several {{w|Linux}} distributions. Many administrative tasks on servers can be automated with cron, like monitoring or updates. Most people administrating a server-like system with a UNIX-like operating system will therefore know it, at least the basics.

When one of these jobs produces output, that output is sent as an email to the user, using the {{w|Sendmail|sendmail}} program. A common situation on many Unix-like systems is that sendmail (or another email program) is not configured to send email to the actual email address of the person behind the user account that configured the cron job, and writes the mail in question to the file <code>/var/mail/username</code> (in {{w|Mbox|mbox}} format) instead. Most shells will check that file, and produce a message "You have new mail" when its timestamps have changed; however, if a person doesn't know how to check their mail they will likely end up just ignoring that message.

The "/etc" directory is used for configuration files on UNIX-systems; therefore "/etc/crontab" is the main configuration file of cron and is expected to contain lines such as the following:

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Comment lines are designated by a # and are ignored, as are blank lines. On a non-comment non-blank line, the first 5 parameters tell it exactly when that line is supposed to run (in this case every hour on the 17th minute of the hour), the next part is what user the command is supposed to run as (root in this case), and the rest is the actual command that is supposed to run (cd / && run-parts --report /etc/cron.hourly). The 5 time parameters, in order are minutes, hours, day-of-month, month, and day-of-week. A * means everything matches. So something could run as frequently as every minute (* * * * *) or as infrequently as once a year (e.g., January 2nd at 10:20am is 20 10 2 1 *), once every four years (once on each February 29th), four times in every 28 years (once each time that a particular day of the year falls on a particular day of the week), or even once every 28 years (only when February has a 29th day that is on a specific day of the week). If a line that doesn't follow the correct format is added to /etc/crontab, it may cause the entire crontab file to be ignored, even those entries that are otherwise valid.

When a cron job runs, it is expected to do something with all text that might normally go to the screen (technically UNIX standard output and standard error streams, aka stdout and stderr respectively) -- a lot of times a command will redirect it to a log file of its own, or deliberately make it go nowhere (/dev/null). If anything does end up "on the screen", cron captures it and sends it as an email to the user, assuming it's data the user wants to view and be aware of. If local email is not configured to go somewhere the user actually knows to check (for example using the nullmailer sendmail replacement which can collect all mails to an existing administrative central address), it usually ends up tacked on to the end of a file in /var/mail/username where it will sit forever, or until the user actually does something with it (either configures a local email program, sets up a forward to an email account they actually check, or deletes the file). Ponytail's suggestion to "fix the cron" means figure out why the cron job is outputting data to the screen, which is thus generating an email, and instead having the cron job handle its own messages in a better way. Once the cron jobs are no longer "talking" all the time, her further suggestion to point the MAILTO= to somewhere else would help Cueball be immediately aware if something goes wrong with a cron job that is normally quiet, so he can address the problem immediately instead of it going on for years undetected.

[[Cueball]] is not aware of all of the above, and expresses surprise at the repeated messages. [[Ponytail]] tells him to check <code>/var/mail/cueball</code> which contains a lot of messages from cron from all those 15 years he used cron without properly understanding how it works.

When he realizes what has happened, he configures the mail system so that it writes all mail for his user to the <code>/etc/crontab</code> file, which is the main configuration file of cron (the <code>{{W|/etc}}</code> directory is used for configuration files on Unix-like systems), most probably breaking it. Of course, none of the jobs normally scheduled to run will run anymore either, so he will likely be surprised when other things that used to work no longer work. There are a number of system cron jobs that are usually present on Linux and Unix-like systems that one would not want to disable, including checking for updates, rotating log files including deleting old logs files, backups, etc.

In the worst case, cron might actually see the junk that [[Cueball]] is now directing into its configuration as valid configuration data and produce even more mail – resulting in a feedback situation that would eventually fill up the disk partition. It's unclear (especially to [[Cueball]]) whether this is actually possible – but it's certainly a risk. If there are other users on the system or if that system is able to receive mail from outside (unlikely here), they could use this as a privilege escalation attack, gaining root rights because /etc/crontab jobs run, by default, on user root. The fact that some cron implementations ignore a configuration file completely when it contains error will make this attack impossible because of the cruft in any e-mail (headers e.g.).

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.

==Transcript==
:[Cueball is sitting at a table in an office chair working on his laptop. Ponytail walks up to him.]
:Cueball: I've been getting these "You have new mail" UNIX notifications for like 15 years, but I've never bothered to figure out what it's talking about.

:[Ponytail has stopped behind Cueball who is typing on his laptop. When Ponytail (and later Cueball) mentions code, the text uses both small and capital letters (as opposed to only capital letters in all other text).]
:Ponytail: Look in /var/mail?
:Cueball: OK...
:Cueball: Oh, wow, there's like a gigabyte of stuff from Cron in here.

:[In a frame-less panel Ponytail is facepalming. Cueball is replying from off-panel with a starburst indicating his position.]
:Ponytail: *Sigh*
:Ponytail: You should fix your Cron, then point "MAILTO=" somewhere you actually see-
:Cueball (off-panel): Better idea:

:[Same setting as panel 2 but Cueball is visibly typing on the laptop as shown with three small curved lines over his hands on the keyboard.]
:Cueball: export MAILTO=/etc/crontab
:Cueball: There. Your move, Cron.
:Ponytail: Wow. Hardball.
:Cueball: Let's see how important it thinks that mail really is.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Computers]]

1728: Cron Mail

2016-09-04T09:40:06Z

Alphanet: /* Explanation */

{{comic
| number = 1728
| date = September 2, 2016
| title = Cron Mail
| image = cron_mail.png
| titletext = Take THAT, piece of 1980s-era infrastructure I've inexplicably maintained on my systems for 15 years despite never really learning how it works.
}}

==Explanation==
{{incomplete|Format information, the bottom two paragraphs should be at the top. Also shorten and simplify explanation.}}
On {{W|Unix}}-like systems, {{W|Cron|cron}} is a system program running in background which allows one to schedule jobs to run at well-defined time slots. It is conceptually the same software which has been used since, at least, the 1980s and is still heavily used in modern operating systems, for example in several {{w|Linux}} distributions. Many administrative tasks on servers can be automated with cron, like monitoring or updates. Most people administrating a server-like system with a UNIX-like operating system will therefore know it, at least the basics.

When one of these jobs produces output, that output is sent as an email to the user, using the {{w|Sendmail|sendmail}} program. A common situation on many Unix-like systems is that sendmail (or another email program) is not configured to send email to the actual email address of the person behind the user account that configured the cron job, and writes the mail in question to the file <code>/var/mail/username</code> (in {{w|Mbox|mbox}} format) instead. Most shells will check that file, and produce a message "You have new mail" when its timestamps have changed; however, if a person doesn't know how to check their mail they will likely end up just ignoring that message.

The "/etc" directory is used for configuration files on UNIX-systems; therefore "/etc/crontab" is the main configuration file of cron and is expected to contain lines such as the following:

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Comment lines are designated by a # and are ignored, as are blank lines. On a non-comment non-blank line, the first 5 parameters tell it exactly when that line is supposed to run (in this case every hour on the 17th minute of the hour), the next part is what user the command is supposed to run as (root in this case), and the rest is the actual command that is supposed to run (cd / && run-parts --report /etc/cron.hourly). The 5 time parameters, in order are minutes, hours, day-of-month, month, and day-of-week. A * means everything matches. So something could run as frequently as every minute (* * * * *) or as infrequently as once a year (e.g., January 2nd at 10:20am is 20 10 2 1 *), once every four years (once on each February 29th), four times in every 28 years (once each time that a particular day of the year falls on a particular day of the week), or even once every 28 years (only when February has a 29th day that is on a specific day of the week). If a line that doesn't follow the correct format is added to /etc/crontab, it may cause the entire crontab file to be ignored, even those entries that are otherwise valid.

When a cron job runs, it is expected to do something with all text that might normally go to the screen (technically UNIX standard output and standard error streams, aka stdout and stderr respectively) -- a lot of times a command will redirect it to a log file of its own, or deliberately make it go nowhere (/dev/null). If anything does end up "on the screen", cron captures it and sends it as an email to the user, assuming it's data the user wants to view and be aware of. If local email is not configured to go somewhere the user actually knows to check (for example using the nullmailer sendmail replacement which can collect all mails to an existing administrative central address), it usually ends up tacked on to the end of a file in /var/mail/username where it will sit forever, or until the user actually does something with it (either configures a local email program, sets up a forward to an email account they actually check, or deletes the file). Ponytail's suggestion to "fix the cron" means figure out why the cron job is outputting data to the screen, which is thus generating an email, and instead having the cron job handle its own messages in a better way. Once the cron jobs are no longer "talking" all the time, her further suggestion to point the MAILTO= to somewhere else would help Cueball be immediately aware if something goes wrong with a cron job that is normally quiet, so he can address the problem immediately instead of it going on for years undetected.

[[Cueball]] is not aware of all of the above, and expresses surprise at the repeated messages. [[Ponytail]] tells him to check <code>/var/mail/cueball</code> which contains a lot of messages from cron from all those 15 years he used cron without properly understanding how it works.

When he realizes what has happened, he configures the mail system so that it writes all mail for his user to the <code>/etc/crontab</code> file, which is the main configuration file of cron (the <code>{{W|/etc}}</code> directory is used for configuration files on Unix-like systems), most probably breaking it. Of course, none of the jobs normally scheduled to run will run anymore either, so he will likely be surprised when other things that used to work no longer work. There are a number of system cron jobs that are usually present on Linux and Unix-like systems that one would not want to disable, including checking for updates, rotating log files including deleting old logs files, backups, etc.

In the worst case, cron might actually see the junk that [[Cueball]] is now directing into its configuration as valid configuration data and produce even more mail – resulting in a feedback situation that would eventually fill up the disk partition. It's unclear (especially to [[Cueball]]) whether this is actually possible – but it's certainly a risk. If there are other users on the system or if that system is able to receive mail from outside (unlikely here), they could use this as a privilege escalation attack, gaining root rights because /etc/crontab jobs run, by default, on user root. The fact that some cron implementation ignore a configuration file completely when it contains error will make this attack impossible because of the cruft in any e-mail (headers e.g.).

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.

==Transcript==
:[Cueball is sitting at a table in an office chair working on his laptop. Ponytail walks up to him.]
:Cueball: I've been getting these "You have new mail" UNIX notifications for like 15 years, but I've never bothered to figure out what it's talking about.

:[Ponytail has stopped behind Cueball who is typing on his laptop. When Ponytail (and later Cueball) mentions code, the text uses both small and capital letters (as opposed to only capital letters in all other text).]
:Ponytail: Look in /var/mail?
:Cueball: OK...
:Cueball: Oh, wow, there's like a gigabyte of stuff from Cron in here.

:[In a frame-less panel Ponytail is facepalming. Cueball is replying from off-panel with a starburst indicating his position.]
:Ponytail: *Sigh*
:Ponytail: You should fix your Cron, then point "MAILTO=" somewhere you actually see-
:Cueball (off-panel): Better idea:

:[Same setting as panel 2 but Cueball is visibly typing on the laptop as shown with three small curved lines over his hands on the keyboard.]
:Cueball: export MAILTO=/etc/crontab
:Cueball: There. Your move, Cron.
:Ponytail: Wow. Hardball.
:Cueball: Let's see how important it thinks that mail really is.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Computers]]

1728: Cron Mail

2016-09-04T09:38:00Z

Alphanet: /* Explanation */

{{comic
| number = 1728
| date = September 2, 2016
| title = Cron Mail
| image = cron_mail.png
| titletext = Take THAT, piece of 1980s-era infrastructure I've inexplicably maintained on my systems for 15 years despite never really learning how it works.
}}

==Explanation==
{{incomplete|Format information, the bottom two paragraphs should be at the top. Also shorten and simplify explanation.}}
On {{W|Unix}}-like systems, {{W|Cron|cron}} is a system program running in background which allows one to schedule jobs to run at well-defined time slots. It is conceptually the same software which has been used since, at least, the 1980s and is still heavily used in modern operating systems, for example in several {{w|Linux}} distributions. Many administrative tasks on servers can be automated with cron, like monitoring or updates. Most people administrating a server-like system with a UNIX-like operating system will therefore know it, at least the basics.

When one of these jobs produces output, that output is sent as an email to the user, using the {{w|Sendmail|sendmail}} program. A common situation on many Unix-like systems is that sendmail (or another email program) is not configured to send email to the actual email address of the person behind the user account that configured the cron job, and writes the mail in question to the file <code>/var/mail/username</code> (in {{w|Mbox|mbox}} format) instead. Most shells will check that file, and produce a message "You have new mail" when its timestamps have changed; however, if a person doesn't know how to check their mail they will likely end up just ignoring that message.

The "/etc" directory is used for configuration files on UNIX-systems; therefore "/etc/crontab" is the main configuration file of cron and is expected to contain lines such as the following:

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Comment lines are designated by a # and are ignored, as are blank lines. On a non-comment non-blank line, the first 5 parameters tell it exactly when that line is supposed to run (in this case every hour on the 17th minute of the hour), the next part is what user the command is supposed to run as (root in this case), and the rest is the actual command that is supposed to run (cd / && run-parts --report /etc/cron.hourly). The 5 time parameters, in order are minutes, hours, day-of-month, month, and day-of-week. A * means everything matches. So something could run as frequently as every minute (* * * * *) or as infrequently as once a year (e.g., January 2nd at 10:20am is 20 10 2 1 *), once every four years (once on each February 29th), four times in every 28 years (once each time that a particular day of the year falls on a particular day of the week), or even once every 28 years (only when February has a 29th day that is on a specific day of the week). If a line that doesn't follow the correct format is added to /etc/crontab, it may cause the entire crontab file to be ignored, even those entries that are otherwise valid.

When a cron job runs, it is expected to do something with all text that might normally go to the screen (technically UNIX standard output and standard error streams, aka stdout and stderr respectively) -- a lot of times a command will redirect it to a log file of its own, or deliberately make it go nowhere (/dev/null). If anything does end up "on the screen", cron captures it and sends it as an email to the user, assuming it's data the user wants to view and be aware of. If local email is not configured to go somewhere the user actually knows to check (for example using the nullmailer sendmail replacement which can collect all mails to an existing administrative central address), it usually ends up tacked on to the end of a file in /var/mail/username where it will sit forever, or until the user actually does something with it (either configures a local email program, sets up a forward to an email account they actually check, or deletes the file). Ponytail's suggestion to "fix the cron" means figure out why the cron job is outputting data to the screen, which is thus generating an email, and instead having the cron job handle its own messages in a better way. Once the cron jobs are no longer "talking" all the time, her further suggestion to point the MAILTO= to somewhere else would help Cueball be immediately aware if something goes wrong with a cron job that is normally quiet, so he can address the problem immediately instead of it going on for years undetected.

[[Cueball]] is not aware of all of the above, and expresses surprise at the repeated messages. [[Ponytail]] tells him to check <code>/var/mail/cueball</code> which contains a lot of messages from cron from all those 15 years he used cron without properly understanding how it works.

When he realizes what has happened, he configures the mail system so that it writes all mail for his user to the <code>/etc/crontab</code> file, which is the main configuration file of cron (the <code>{{W|/etc}}</code> directory is used for configuration files on Unix-like systems), most probably breaking it. Of course, none of the jobs normally scheduled to run will run anymore either, so he will likely be surprised when other things that used to work no longer work. There are a number of system cron jobs that are usually present on Linux and Unix-like systems that one would not want to disable, including checking for updates, rotating log files including deleting old logs files, backups, etc.

In the worst case, cron might actually see the junk that [[Cueball]] is now directing into its configuration as valid configuration data and produce even more mail – resulting in a feedback situation that would eventually fill up the disk partition. It's unclear (especially to [[Cueball]]) whether this is actually possible – but it's certainly a risk. If there are other users on the system or if that system is able to receive mail from outside (unlikely here), they could use this as a privilege escalation attack, gaining root rights because /etc/crontab jobs run, by default, on user root.

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.

==Transcript==
:[Cueball is sitting at a table in an office chair working on his laptop. Ponytail walks up to him.]
:Cueball: I've been getting these "You have new mail" UNIX notifications for like 15 years, but I've never bothered to figure out what it's talking about.

:[Ponytail has stopped behind Cueball who is typing on his laptop. When Ponytail (and later Cueball) mentions code, the text uses both small and capital letters (as opposed to only capital letters in all other text).]
:Ponytail: Look in /var/mail?
:Cueball: OK...
:Cueball: Oh, wow, there's like a gigabyte of stuff from Cron in here.

:[In a frame-less panel Ponytail is facepalming. Cueball is replying from off-panel with a starburst indicating his position.]
:Ponytail: *Sigh*
:Ponytail: You should fix your Cron, then point "MAILTO=" somewhere you actually see-
:Cueball (off-panel): Better idea:

:[Same setting as panel 2 but Cueball is visibly typing on the laptop as shown with three small curved lines over his hands on the keyboard.]
:Cueball: export MAILTO=/etc/crontab
:Cueball: There. Your move, Cron.
:Ponytail: Wow. Hardball.
:Cueball: Let's see how important it thinks that mail really is.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Computers]]

1728: Cron Mail

2016-09-04T09:36:11Z

Alphanet: /* UNIX stdxx */

{{comic
| number = 1728
| date = September 2, 2016
| title = Cron Mail
| image = cron_mail.png
| titletext = Take THAT, piece of 1980s-era infrastructure I've inexplicably maintained on my systems for 15 years despite never really learning how it works.
}}

==Explanation==
{{incomplete|Format information, the bottom two paragraphs should be at the top. Also shorten and simplify explanation.}}
On {{W|Unix}}-like systems, {{W|Cron|cron}} is a system program running in background which allows one to schedule jobs to run at well-defined time slots. It is conceptually the same software which has been used since, at least, the 1980s and is still heavily used in modern operating systems, for example in several {{w|Linux}} distributions. Many administrative tasks on servers can be automated with cron, like monitoring or updates. Most people administrating a server-like system with a UNIX-like operating system will therefore know it, at least the basics.

When one of these jobs produces output, that output is sent as an email to the user, using the {{w|Sendmail|sendmail}} program. A common situation on many Unix-like systems is that sendmail (or another email program) is not configured to send email to the actual email address of the person behind the user account that configured the cron job, and writes the mail in question to the file <code>/var/mail/username</code> (in {{w|Mbox|mbox}} format) instead. Most shells will check that file, and produce a message "You have new mail" when its timestamps have changed; however, if a person doesn't know how to check their mail they will likely end up just ignoring that message.

The "/etc" directory is used for configuration files on UNIX-systems; therefore "/etc/crontab" is the main configuration file of cron and is expected to contain lines such as the following:

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Comment lines are designated by a # and are ignored, as are blank lines. On a non-comment non-blank line, the first 5 parameters tell it exactly when that line is supposed to run (in this case every hour on the 17th minute of the hour), the next part is what user the command is supposed to run as (root in this case), and the rest is the actual command that is supposed to run (cd / && run-parts --report /etc/cron.hourly). The 5 time parameters, in order are minutes, hours, day-of-month, month, and day-of-week. A * means everything matches. So something could run as frequently as every minute (* * * * *) or as infrequently as once a year (e.g., January 2nd at 10:20am is 20 10 2 1 *), once every four years (once on each February 29th), four times in every 28 years (once each time that a particular day of the year falls on a particular day of the week), or even once every 28 years (only when February has a 29th day that is on a specific day of the week). If a line that doesn't follow the correct format is added to /etc/crontab, it may cause the entire crontab file to be ignored, even those entries that are otherwise valid.

When a cron job runs, it is expected to do something with all text that might normally go to the screen (technically UNIX standard output and standard error streams, aka stdout and stderr respectively) -- a lot of times a command will redirect it to a log file of its own, or deliberately make it go nowhere (/dev/null). If anything does end up "on the screen", cron captures it and sends it as an email to the user, assuming it's data the user wants to view and be aware of. If local email is not configured to go somewhere the user actually knows to check (for example using the nullmailer sendmail replacement which can collect all mails to an existing administrative central address), it usually ends up tacked on to the end of a file in /var/mail/username where it will sit forever, or until the user actually does something with it (either configures a local email program, sets up a forward to an email account they actually check, or deletes the file). Ponytail's suggestion to "fix the cron" means figure out why the cron job is outputting data to the screen, which is thus generating an email, and instead having the cron job handle its own messages in a better way. Once the cron jobs are no longer "talking" all the time, her further suggestion to point the MAILTO= to somewhere else would help Cueball be immediately aware if something goes wrong with a cron job that is normally quiet, so he can address the problem immediately instead of it going on for years undetected.

[[Cueball]] is not aware of all of the above, and expresses surprise at the repeated messages. [[Ponytail]] tells him to check <code>/var/mail/cueball</code> which contains a lot of messages from cron from all those 15 years he used cron without properly understanding how it works.

When he realizes what has happened, he configures the mail system so that it writes all mail for his user to the <code>/etc/crontab</code> file, which is the main configuration file of cron (the <code>{{W|/etc}}</code> directory is used for configuration files on Unix-like systems), most probably breaking it. Of course, none of the jobs normally scheduled to run will run anymore either, so he will likely be surprised when other things that used to work no longer work. There are a number of system cron jobs that are usually present on Linux and Unix-like systems that one would not want to disable, including checking for updates, rotating log files including deleting old logs files, backups, etc.

In the worst case, cron might actually see the junk that [[Cueball]] is now directing into its configuration as valid configuration data and produce even more mail – resulting in a feedback situation that would eventually fill up the disk partition. It's unclear (especially to [[Cueball]]) whether this is actually possible – but it's certainly a risk.

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.

==Transcript==
:[Cueball is sitting at a table in an office chair working on his laptop. Ponytail walks up to him.]
:Cueball: I've been getting these "You have new mail" UNIX notifications for like 15 years, but I've never bothered to figure out what it's talking about.

:[Ponytail has stopped behind Cueball who is typing on his laptop. When Ponytail (and later Cueball) mentions code, the text uses both small and capital letters (as opposed to only capital letters in all other text).]
:Ponytail: Look in /var/mail?
:Cueball: OK...
:Cueball: Oh, wow, there's like a gigabyte of stuff from Cron in here.

:[In a frame-less panel Ponytail is facepalming. Cueball is replying from off-panel with a starburst indicating his position.]
:Ponytail: *Sigh*
:Ponytail: You should fix your Cron, then point "MAILTO=" somewhere you actually see-
:Cueball (off-panel): Better idea:

:[Same setting as panel 2 but Cueball is visibly typing on the laptop as shown with three small curved lines over his hands on the keyboard.]
:Cueball: export MAILTO=/etc/crontab
:Cueball: There. Your move, Cron.
:Ponytail: Wow. Hardball.
:Cueball: Let's see how important it thinks that mail really is.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Computers]]

1728: Cron Mail

2016-09-04T09:34:05Z

Alphanet: /* nullmailer */

{{comic
| number = 1728
| date = September 2, 2016
| title = Cron Mail
| image = cron_mail.png
| titletext = Take THAT, piece of 1980s-era infrastructure I've inexplicably maintained on my systems for 15 years despite never really learning how it works.
}}

==Explanation==
{{incomplete|Format information, the bottom two paragraphs should be at the top. Also shorten and simplify explanation.}}
On {{W|Unix}}-like systems, {{W|Cron|cron}} is a system program running in background which allows one to schedule jobs to run at well-defined time slots. It is conceptually the same software which has been used since, at least, the 1980s and is still heavily used in modern operating systems, for example in several {{w|Linux}} distributions. Many administrative tasks on servers can be automated with cron, like monitoring or updates. Most people administrating a server-like system with a UNIX-like operating system will therefore know it, at least the basics.

When one of these jobs produces output, that output is sent as an email to the user, using the {{w|Sendmail|sendmail}} program. A common situation on many Unix-like systems is that sendmail (or another email program) is not configured to send email to the actual email address of the person behind the user account that configured the cron job, and writes the mail in question to the file <code>/var/mail/username</code> (in {{w|Mbox|mbox}} format) instead. Most shells will check that file, and produce a message "You have new mail" when its timestamps have changed; however, if a person doesn't know how to check their mail they will likely end up just ignoring that message.

The "/etc" directory is used for configuration files on UNIX-systems; therefore "/etc/crontab" is the main configuration file of cron and is expected to contain lines such as the following:

#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly

Comment lines are designated by a # and are ignored, as are blank lines. On a non-comment non-blank line, the first 5 parameters tell it exactly when that line is supposed to run (in this case every hour on the 17th minute of the hour), the next part is what user the command is supposed to run as (root in this case), and the rest is the actual command that is supposed to run (cd / && run-parts --report /etc/cron.hourly). The 5 time parameters, in order are minutes, hours, day-of-month, month, and day-of-week. A * means everything matches. So something could run as frequently as every minute (* * * * *) or as infrequently as once a year (e.g., January 2nd at 10:20am is 20 10 2 1 *), once every four years (once on each February 29th), four times in every 28 years (once each time that a particular day of the year falls on a particular day of the week), or even once every 28 years (only when February has a 29th day that is on a specific day of the week). If a line that doesn't follow the correct format is added to /etc/crontab, it may cause the entire crontab file to be ignored, even those entries that are otherwise valid.

When a cron job runs, it is expected to do something with all text that might normally go to the screen -- a lot of times a command will redirect it to a log file of its own, or deliberately make it go nowhere (/dev/null). If anything does end up "on the screen", cron captures it and sends it as an email to the user, assuming it's data the user wants to view and be aware of. If local email is not configured to go somewhere the user actually knows to check (for example using the nullmailer sendmail replacement which can collect all mails to an existing administrative central address), it usually ends up tacked on to the end of a file in /var/mail/username where it will sit forever, or until the user actually does something with it (either configures a local email program, sets up a forward to an email account they actually check, or deletes the file). Ponytail's suggestion to "fix the cron" means figure out why the cron job is outputting data to the screen, which is thus generating an email, and instead having the cron job handle its own messages in a better way. Once the cron jobs are no longer "talking" all the time, her further suggestion to point the MAILTO= to somewhere else would help Cueball be immediately aware if something goes wrong with a cron job that is normally quiet, so he can address the problem immediately instead of it going on for years undetected.

[[Cueball]] is not aware of all of the above, and expresses surprise at the repeated messages. [[Ponytail]] tells him to check <code>/var/mail/cueball</code> which contains a lot of messages from cron from all those 15 years he used cron without properly understanding how it works.

When he realizes what has happened, he configures the mail system so that it writes all mail for his user to the <code>/etc/crontab</code> file, which is the main configuration file of cron (the <code>{{W|/etc}}</code> directory is used for configuration files on Unix-like systems), most probably breaking it. Of course, none of the jobs normally scheduled to run will run anymore either, so he will likely be surprised when other things that used to work no longer work. There are a number of system cron jobs that are usually present on Linux and Unix-like systems that one would not want to disable, including checking for updates, rotating log files including deleting old logs files, backups, etc.

In the worst case, cron might actually see the junk that [[Cueball]] is now directing into its configuration as valid configuration data and produce even more mail – resulting in a feedback situation that would eventually fill up the disk partition. It's unclear (especially to [[Cueball]]) whether this is actually possible – but it's certainly a risk.

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.

==Transcript==
:[Cueball is sitting at a table in an office chair working on his laptop. Ponytail walks up to him.]
:Cueball: I've been getting these "You have new mail" UNIX notifications for like 15 years, but I've never bothered to figure out what it's talking about.

:[Ponytail has stopped behind Cueball who is typing on his laptop. When Ponytail (and later Cueball) mentions code, the text uses both small and capital letters (as opposed to only capital letters in all other text).]
:Ponytail: Look in /var/mail?
:Cueball: OK...
:Cueball: Oh, wow, there's like a gigabyte of stuff from Cron in here.

:[In a frame-less panel Ponytail is facepalming. Cueball is replying from off-panel with a starburst indicating his position.]
:Ponytail: *Sigh*
:Ponytail: You should fix your Cron, then point "MAILTO=" somewhere you actually see-
:Cueball (off-panel): Better idea:

:[Same setting as panel 2 but Cueball is visibly typing on the laptop as shown with three small curved lines over his hands on the keyboard.]
:Cueball: export MAILTO=/etc/crontab
:Cueball: There. Your move, Cron.
:Ponytail: Wow. Hardball.
:Cueball: Let's see how important it thinks that mail really is.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Computers]]