Editing Talk:1728: Cron Mail
Please sign your posts with ~~~~ |
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 7: | Line 7: | ||
: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) | ||
:Seems like it wouldn't break the existing stuff, they'd still get run and then cron would start parsing the noise and complaining - the "intermediate" situation, though the "export MAILTO" seems wrong. If Cueball did it in his .bashrc, it might get into some of *his* cron jobs but unless it's in /etc/crontab (and there, no "export" is needed/used), it wouldn't matter. His jobs probably wouldn't have rights to write to /etc/crontab either. [[Special:Contributions/173.245.48.73|173.245.48.73]] 17:09, 2 September 2016 (UTC) | :Seems like it wouldn't break the existing stuff, they'd still get run and then cron would start parsing the noise and complaining - the "intermediate" situation, though the "export MAILTO" seems wrong. If Cueball did it in his .bashrc, it might get into some of *his* cron jobs but unless it's in /etc/crontab (and there, no "export" is needed/used), it wouldn't matter. His jobs probably wouldn't have rights to write to /etc/crontab either. [[Special:Contributions/173.245.48.73|173.245.48.73]] 17:09, 2 September 2016 (UTC) | ||
− | |||
− | |||
:Unfortunately this huge question is undecidable (by trivial reduction to halting problem) --[[Special:Contributions/172.68.54.126|172.68.54.126]] 08:10, 3 September 2016 (UTC) | :Unfortunately this huge question is undecidable (by trivial reduction to halting problem) --[[Special:Contributions/172.68.54.126|172.68.54.126]] 08:10, 3 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'. {{unsigned ip|141.101.98.90}} | 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'. {{unsigned ip|141.101.98.90}} | ||
Line 66: | Line 64: | ||
::What makes you think he never upgraded? Lot of distributions allow to be upgraded without losing /var/spool/mail, and if the problem is caused by bad configuration, it can similarly "survive" several upgrades, especially if done by Cueball ("configuration file was changed - update? Nah ...") | ::What makes you think he never upgraded? Lot of distributions allow to be upgraded without losing /var/spool/mail, and if the problem is caused by bad configuration, it can similarly "survive" several upgrades, especially if done by Cueball ("configuration file was changed - update? Nah ...") | ||
::Oh, and one think cron is CERTAINLY doing is rotating log files. And because linux computer ALWAYS generates at least some log files, killing cron can still fill the disk. Only way Cueball can win is if the problematic command is in /etc/crontab, the useful commands are in /etc/cron.d/ and adding mail to /etc/crontab will make cron ignore /etc/crontab. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 21:22, 4 September 2016 (UTC) | ::Oh, and one think cron is CERTAINLY doing is rotating log files. And because linux computer ALWAYS generates at least some log files, killing cron can still fill the disk. Only way Cueball can win is if the problematic command is in /etc/crontab, the useful commands are in /etc/cron.d/ and adding mail to /etc/crontab will make cron ignore /etc/crontab. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 21:22, 4 September 2016 (UTC) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
I like the comics about the tech-inept Cueball and the embarrassed/condescending Ponytail. [[Special:Contributions/108.162.210.196|108.162.210.196]] 04:26, 5 September 2016 (UTC) | I like the comics about the tech-inept Cueball and the embarrassed/condescending Ponytail. [[Special:Contributions/108.162.210.196|108.162.210.196]] 04:26, 5 September 2016 (UTC) | ||
− | |||
− |