Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
Excerpts from Christian Kastner's message of Wed May 19 10:10:25 -0700 2010: I just re-read #443615. I understand the wish for such a feature, and have added it to my ideas list (among #373152 et al). Such a feature could be added in squeeze+1, via a --strict flag or similar, but I won't promise it. For now, I suggest Andrew do the inverse of your suggestion and add || echo FOO failed to those entries for which a mail should be sent on non-zero exit. Yes, now that I know about the problem, I try to do something like this. Thanks for considering the problem. I really think that reporting a non-zero exit should be the default. There's little point in a --strict flag, because those who know about the problem can work-around it as you showed. I understand if you can't make this change in the current release cycle, but I think it would be a good idea for the next one. Making failures visible will make the whole system more solid in the end. (And I won't have to explain to the boss why the reports weren't running when I thought they were.) Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
On 05/19/2010 12:03 AM, Justin T Pryzby wrote:
clone 581612 -1
reassign -1 php4
retitle -1 php4: update test avoiding nonzero exit status when
removed-but-not-purged
thanks
If it is desired behavior that cron now sends out email if the job
exit's with
status 1, it is strange that I now get a lot of mail from system cron
jobs
Those packages should be considered buggy with the new cron.
That does redirect both std{out,err} to /dev/null. However, killall
exists nonzero when it doesn't kill anything. Cron (the new version)
tries harder to make failures more obvious.
I think our mails triggered a race condition ;-)
I have to admit the change was unintended, which is why I reverted it.
Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#155109: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
You want cron to allow a job to fail silently? Although avoiding noise from some existing package cron.d jobs is additional work, having an assertive cron helps people to catch otherwise-invisible problems (Andrew Pimlott in #443615). Andrew? Perhaps you have a specific, convincing scenario handy. Justin On Wed, May 19, 2010 at 09:58:06AM +0200, Christian Kastner wrote: I think our mails triggered a race condition ;-) I have to admit the change was unintended, which is why I reverted it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#155109: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
On 05/19/2010 03:28 PM, Justin Pryzby wrote: You want cron to allow a job to fail silently? The question is not what I want to do, it's what can I /can/ do. Although avoiding noise from some existing package cron.d jobs is additional work, having an assertive cron helps people to catch otherwise-invisible problems (Andrew Pimlott in #443615). Andrew? Perhaps you have a specific, convincing scenario handy. I consider this a major change, not only for our cron but also from all other vixie-cron based implementations out there. It would be absolutely impossible to implement this change responsibly on such short notice (ie, for squeeze). As you said, this would probably cause issues for other packages. This means that I would have to conduct a MBF and give Maintainers time to fix this. And the impact on users would be even worse, NEWS entry or not (the fetchmail issue alone, with 6% popcon, would be bad enough). I just re-read #443615. I understand the wish for such a feature, and have added it to my ideas list (among #373152 et al). Such a feature could be added in squeeze+1, via a --strict flag or similar, but I won't promise it. For now, I suggest Andrew do the inverse of your suggestion and add || echo FOO failed to those entries for which a mail should be sent on non-zero exit. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
I upgraded my machine today. After about a hour I had 22-25 mails nagging me that my different cron jobs telling me the same: command failed with exit status 1 The error came from the following cron jobs: /etc/cron.d/dma: */5 * * * * root[ -x /usr/sbin/dma ] /usr/sbin/dma -q1 /etc/cron.d/php4: 09,39 * * * * root [ -d /var/lib/php4 ] find /var/lib/php4/ -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm and a private cron job: */5 * * * *killall nspluginviewer /dev/null 21 If it is desired behavior that cron now sends out email if the job exit's with status 1, it is strange that I now get a lot of mail from system cron jobs In my private cron job I'm killing the nspluginviewer every 5 minute. I'm aware that the nspluginviewer probably are not running, but that is why I pipe the error message to /dev/null. I don't want to hear about it. I thought that 21 would send the ERROUT to the same place as STDOUT... Why do cron catch these then? I'm running 3.0pl1-110. Not sure what I had before the upgrade. -- -Frode I never forget a face, but in your case I'll make an exception. -- Groucho Marx signature.asc Description: This is a digitally signed message part.
Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)
clone 581612 -1
reassign -1 php4
retitle -1 php4: update test avoiding nonzero exit status when
removed-but-not-purged
thanks
If it is desired behavior that cron now sends out email if the job exit's
with
status 1, it is strange that I now get a lot of mail from system cron jobs
Those packages should be considered buggy with the new cron.
and a private cron job:
*/5 * * * *killall nspluginviewer /dev/null 21
I thought that 21 would send the ERROUT to the same place as STDOUT... Why
do cron catch these then?
That does redirect both std{out,err} to /dev/null. However, killall
exists nonzero when it doesn't kill anything. Cron (the new version)
tries harder to make failures more obvious. If you want to run that
command silently, change it to:
killall nspluginviewer /dev/null 21 || true
or (slightly more assertive):
killall nspluginviewer /dev/null 21 || [ $? -eq 1 ]
/etc/cron.d/php4:
09,39 * * * * root [ -d /var/lib/php4 ] find /var/lib/php4/
-type
f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm
That could be rewritten as:
d=/var/lib/php4; [ ! -d $d ] exit; find $d -type f ... -print0
|xargs -r0 rm
Then, when php4 is in dpkg state rc (removed but not purged/config
files), the test succeeds, and the shell exists. Right now, the test
fails, and the shell exists nonzero, and (new) cron warns you, even if
though command doesn't itself write any output.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
