Debian Bug report logs - #581612
cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Fri, 14 May 2010 11:59:22 +0200

Package: cron
Version: 3.0pl1-110
Severity: important


Hi,

On two different machines I have some cron jobs failing after upgrading from 3.0pl1-105 to 3.0pl1-110. Involved MTA is postfix in both cases. Downgrading to 3.0pl1-105 makes the issue go away again.

For example, the below cronjob normally executes without output, within 1-2 seconds.

# m h  dom mon dow   command
*/2     *       *       *       *       /usr/bin/fetchmail -s >/dev/null 2>&1

Now it fails:

May 14 11:44:02 server /USR/SBIN/CRON[8853]: (robbert) CMD (/usr/bin/fetchmail -s >/dev/null 2>&1)
May 14 11:44:03 server /USR/SBIN/CRON[8852]: (CRON) error (grandchild #8853 failed with exit status 1)

After which cron sends an e-mail, with: 

Subject: Cron <robbert@awakenings> /usr/bin/fetchmail -s >/dev/null 2>&1 (failed)
Content-Type: text/plain; charset=UTF-8
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/home/robbert>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=robbert>
Message-Id: <20100514094403.17B9F19BF3@server>
Date: Fri, 14 May 2010 11:44:03 +0200 (CEST)

command failed with exit status 1

Regards,
Robbert


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cron depends on:
ii  adduser                       3.112      add and remove users and groups
ii  debianutils                   3.2.3      Miscellaneous utilities specific t
ii  libc6                         2.10.2-6   Embedded GNU C Library: Shared lib
ii  libpam-runtime                1.1.1-3    Runtime support for the PAM librar
ii  libpam0g                      1.1.1-3    Pluggable Authentication Modules l
ii  libselinux1                   2.0.94-1   SELinux runtime shared libraries
ii  lsb-base                      3.2-23.1   Linux Standard Base 3.2 init scrip

Versions of packages cron recommends:
ii  lockfile-progs                0.1.13     Programs for locking and unlocking
ii  postfix [mail-transport-agent 2.6.5-3    High-performance mail transport ag

Versions of packages cron suggests:
pn  anacron                       <none>     (no description available)
pn  checksecurity                 <none>     (no description available)
ii  logrotate                     3.7.8-6    Log rotation utility

-- debconf information:
* cron/checksecurity:

Message #10 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Christian Kastner <debian@kvr.at>

To: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>

Cc: 581612@bugs.debian.org

Subject: Re: Bug#581612: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Fri, 14 May 2010 12:59:28 +0200

Hi Robbert,

On 05/14/2010 11:59 AM, Robbert Kouprie wrote:
> On two different machines I have some cron jobs failing after upgrading from 3.0pl1-105 to 3.0pl1-110. Involved MTA is postfix in both cases. Downgrading to 3.0pl1-105 makes the issue go away again.
>
> For example, the below cronjob normally executes without output, within 1-2 seconds.
> 
> # m h  dom mon dow   command
> */2     *       *       *       *       /usr/bin/fetchmail -s >/dev/null 2>&1
> 
> Now it fails:
> 
> May 14 11:44:02 server /USR/SBIN/CRON[8853]: (robbert) CMD (/usr/bin/fetchmail -s >/dev/null 2>&1)
> May 14 11:44:03 server /USR/SBIN/CRON[8852]: (CRON) error (grandchild #8853 failed with exit status 1)

I actually think this is the correct behaviour, and that pre-110 had the
bug.

First, I tested the above with some random commands, and they ran fine.
I then installed fetchmail. Checking fetchmail(1) however, I found this
for exit code 1:

<quote code="1">
There  was no mail awaiting retrieval.  (There may have been old mail
still on the server but not selected for retrieval.) If you do not want
"no mail" to be an  error condition (for instance, for cron jobs), use a
POSIX-compliant shell and add

              || [ $? -eq 1 ]

to the end of the fetchmail command line, note that this leaves  0
untouched, maps 1 to 0, and maps all other codes to 1. See also item #C8
in the FAQ.
</quote>


/usr/share/doc/fetchmail/fetchmail-FAQ.html contains:

C8. Why is "NOMAIL" an error?/I frequently get messages from cron!

which basically says that what you are observing is  1) common and 2)
correct.


I'll take a look at the diff between -105 and -110 and see what could
have caused this change. It'll have to wait until Monday, though.


Christian

Message #15 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Christian Kastner <debian@kvr.at>

To: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>

Cc: 581612@bugs.debian.org

Subject: Re: Bug#581612: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Fri, 14 May 2010 13:12:19 +0200

On 05/14/2010 12:59 PM, Christian Kastner wrote:
> Hi Robbert,
> 
> On 05/14/2010 11:59 AM, Robbert Kouprie wrote:
>> On two different machines I have some cron jobs failing after upgrading from 3.0pl1-105 to 3.0pl1-110. Involved MTA is postfix in both cases. Downgrading to 3.0pl1-105 makes the issue go away again.
>>
>> For example, the below cronjob normally executes without output, within 1-2 seconds.
>>
>> # m h  dom mon dow   command
>> */2     *       *       *       *       /usr/bin/fetchmail -s >/dev/null 2>&1

> First, I tested the above with some random commands, and they ran fine.
> I then installed fetchmail. Checking fetchmail(1) however, I found this
> for exit code 1:
> 
> <quote code="1">
> There  was no mail awaiting retrieval.  (There may have been old mail
> still on the server but not selected for retrieval.) If you do not want
> "no mail" to be an  error condition (for instance, for cron jobs), use a
> POSIX-compliant shell and add
> 
>               || [ $? -eq 1 ]
> 
> to the end of the fetchmail command line, note that this leaves  0
> untouched, maps 1 to 0, and maps all other codes to 1. See also item #C8
> in the FAQ.
> </quote>

One thing that just came to mind: If cron generated mails, that would
probably screw up your testing.

Say that -110 generates a mail. You downgrade to -105; -105 runs fine
(because it gets the mail from -110). You upgrade to -110 again, and
that fails again because of no mail. And so on.

Could this be the case?

Message #20 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>

To: Christian Kastner <debian@kvr.at>

Cc: 581612@bugs.debian.org

Subject: Re: Bug#581612: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Fri, 14 May 2010 19:41:11 +0200

Hi Christian,

Op 14-5-2010 12:59, Christian Kastner schreef:
> I actually think this is the correct behaviour, and that pre-110 had the
> bug.

Actually I think you are right. Fetchmail exiting nonzero on NOMAIL 
seems indeed normal behaviour.

The cronjobs indeed seem to run correctly, but I was misleaded by the 
sudden error e-mails.

So there has been a change in cron behaviour, since it is now sending 
messaged when cronjobs exit nonzero (in my case).

If this indeed is the desired new behaviour of cron, I would think that 
a NEWS entry about this would be very helpful, though.

Regards,
Robbert

PS. In the light of the above I am fine with downgrading the severity of 
this bug.

Message #25 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>

To: Christian Kastner <debian@kvr.at>

Cc: 581612@bugs.debian.org

Subject: Re: Bug#581612: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Fri, 14 May 2010 19:44:37 +0200

Hi Christian,

Op 14-5-2010 13:12, Christian Kastner schreef:
> One thing that just came to mind: If cron generated mails, that would
> probably screw up your testing.
>
> Say that -110 generates a mail. You downgrade to -105; -105 runs fine
> (because it gets the mail from -110). You upgrade to -110 again, and
> that fails again because of no mail. And so on.
>
> Could this be the case?

No, it's not the testing. -105 never sends me e-mails on the fetchmail 
cronjob, even if it exits nonzero. -110 does send an e-mail when 
fetchmail exits nonzero.

Regards,
Robbert

Message #34 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: Robbert Kouprie <robbert@radium.jvb.tudelft.nl>, 581612@bugs.debian.org

Cc: Christian Kastner <debian@kvr.at>

Subject: Re: Bug#581612: cron: Cron jobs fail after upgrade to 3.0pl1-110

Date: Sun, 16 May 2010 19:50:07 +0200

[Message part 1 (text/plain, inline)]

On Fri, May 14, 2010 at 07:41:11PM +0200, Robbert Kouprie wrote:
> If this indeed is the desired new behaviour of cron, I would think
> that a NEWS entry about this would be very helpful, though.

I'm not sure that there should be a NEWS entry for this issue alone. Maybe we
want to add one for both this issue and the new checks that introduce
bug #580887. Users upgrading from earlier Debian releases might certainly
find that the cron checks are more strict and that might have consequences in
the tasks that get eventually run in their system.

Regards

Javier

[signature.asc (application/pgp-signature, inline)]

Message #41 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Frode Jemtland <frode.jemtland@skolelinux.no>

To: 581612@bugs.debian.org

Subject: RE: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Date: Tue, 18 May 2010 22:22:34 +0200

[Message part 1 (text/plain, inline)]

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 2>&1


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 2>&1 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 (application/pgp-signature, inline)]

Message #50 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Justin T Pryzby <justinpryzby@users.sourceforge.net>

To: Frode Jemtland <frode.jemtland@skolelinux.no>, 581612@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Date: Tue, 18 May 2010 15:03:58 -0700

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 2>&1
> I thought that 2>&1 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 2>&1 || true
or (slightly more assertive):
	killall nspluginviewer >/dev/null 2>&1 || [ $? -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.

Message #57 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Christian Kastner <debian@kvr.at>

To: Justin T Pryzby <justinpryzby@users.sourceforge.net>, <581612@bugs.debian.org>

Subject: Re: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Date: Wed, 19 May 2010 09:58:06 +0200

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

Message #62 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Christian Kastner <debian@kvr.at>

To: Justin Pryzby <justinpryzby@users.sourceforge.net>

Cc: Andrew Pimlott <andrew@pimlott.net>, 155109@bugs.debian.org, 581612@bugs.debian.org

Subject: Re: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Date: Wed, 19 May 2010 19:10:25 +0200

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

Message #67 received at 581612@bugs.debian.org (full text, mbox, reply):

From: Andrew Pimlott <andrew@pimlott.net>

To: Christian Kastner <debian@kvr.at>

Cc: Justin Pryzby <justinpryzby@users.sourceforge.net>, 155109@bugs.debian.org, 581612@bugs.debian.org, 443615@bugs.debian.org

Subject: Re: Bug#581612: cron sends e-mails when a job exits nonzero (after upgrade to 3.0pl1-110)

Date: Thu, 20 May 2010 13:39:26 -0700

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

Message #72 received at 581612-close@bugs.debian.org (full text, mbox, reply):

From: Christian Kastner <debian@kvr.at>

To: 581612-close@bugs.debian.org

Subject: Bug#581612: fixed in cron 3.0pl1-112

Date: Sat, 12 Jun 2010 11:17:08 +0000

Source: cron
Source-Version: 3.0pl1-112

We believe that the bug you reported is fixed in the latest version of
cron, which is due to be installed in the Debian FTP archive:

cron_3.0pl1-112.diff.gz
  to main/c/cron/cron_3.0pl1-112.diff.gz
cron_3.0pl1-112.dsc
  to main/c/cron/cron_3.0pl1-112.dsc
cron_3.0pl1-112_i386.deb
  to main/c/cron/cron_3.0pl1-112_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 581612@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Kastner <debian@kvr.at> (supplier of updated cron package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 10 Jun 2010 15:21:39 +0200
Source: cron
Binary: cron
Architecture: source i386
Version: 3.0pl1-112
Distribution: unstable
Urgency: low
Maintainer: Javier Fernandez-Sanguino Pen~a <jfs@debian.org>
Changed-By: Christian Kastner <debian@kvr.at>
Description: 
 cron       - process scheduling daemon
Closes: 304036 460095 581612 585399
Changes: 
 cron (3.0pl1-112) unstable; urgency=low
 .
   [ Christian Kastner ]
   * do_command.c:
     - Don't send mail when a job exits non-zero, only send mail if the job sent
       output to stderr. This behaviour was introduced erroneously; while it
       does have merit, it is completly against standard cron behaviour.
       Closes: #581612
   * debian/compat:
     - Bumped debhelper compatibility to 7
   * debian/control:
     - Bumped Standards-Version to 3.8.4 (no change needed)
     - Build-Depend on debhelper (>= 7.0.50~)
     - Added dependency on ${misc:Depends} to package cron
   * debian/cron.init:
     - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
       3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
       on shutdown/reboot -- was redundant. This, however, also applies to
       rc1, because killprocs will do that for us.
   * debian/postinst:
     - Removed obsolete dpkg file backup code, this has been handed over to dpkg
       in 3.0pl1-109
     - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
     - Add dpkg-statoverride for /usr/bin/crontab, and unconditionally change
       permissions of /var/spool/cron/crontabs. Closes: #304036, #460095
   * debian/standard.monthly:
     - Removed because it had been empty for years and therefore served no
       purpose
   * debian/cron.bug-{control,script}
     - Added to extend information submitted by reportbug
   * debian/rules:
     - Applied changes for standard.monthly and cron.bug-{control,script} above
   * debian/copyright:
     - Updated to reflect recent contributions
   * debian/README:
     - Updated ancient information with the current status (PAM support, SELinux
       support, etc.)
   * debian/TODO:
     - Added new entry regarding clarification of the purpose behind /etc/cron.d
   * debian/REFS:
     - Summary of links to relevant development threads; re-added for
       informational purposes.
   [ Javier Fernandez-Sanguino ]
   * debian/cron.init:
     - Fix typo (Closes: #585399)
Checksums-Sha1: 
 423f87bf9e8ba29220b5a1f42d6bca9588ac2b54 1103 cron_3.0pl1-112.dsc
 97eca50b50a112da79a8384deca02fa4941413d9 85395 cron_3.0pl1-112.diff.gz
 ceb2122ad9bf5e7af8fc2791847647b666fc7419 91606 cron_3.0pl1-112_i386.deb
Checksums-Sha256: 
 e54f7fc23b47a0047010cad5ec23ba2f05cba485e01286943c0b2199482eea11 1103 cron_3.0pl1-112.dsc
 48ab95879a4aa50f1712137c54a89a2964f22079f5ddf8d82078372194e14669 85395 cron_3.0pl1-112.diff.gz
 e09153d9ee305b169156af15707da9ac7568b28e15525f30e7af755adc6c2210 91606 cron_3.0pl1-112_i386.deb
Files: 
 e2d051f02da77039cfce66c34c5fa7f3 1103 admin important cron_3.0pl1-112.dsc
 60b6681492846738b93bd2ea4a9239a7 85395 admin important cron_3.0pl1-112.diff.gz
 3269a47f4c50ffe7817fa4fd1960af76 91606 admin important cron_3.0pl1-112_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFME2NGsandgtyBSwkRAssBAKCAy9g+Ll38Cug72t3OQNw4GqOc1gCfehDg
KyJxUUAwD2PiIKaiRwROJ/c=
=1qWy
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.