Debian Bug report logs - #582182
php4: update test avoiding nonzero exit status when removed-but-not-purged

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 #63 received at 582182-done@bugs.debian.org (full text, mbox, reply):

From: Marco Rodrigues <gothicx@gmail.com>

To: 582182-done@bugs.debian.org

Subject: Package php4 has been removed from Debian

Date: Sun, 5 Sep 2010 10:45:37 +0100 (WEST)

Version: 6:4.4.6-2+rm

You filed the bug http://bugs.debian.org/582182 in Debian BTS
against the package php4. I'm closing it at *unstable*, but it will
remain open for older distributions.

For more information about this package's removal, read
http://bugs.debian.org/428266. That bug might give the reasons why
this package was removed and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.

--
Marco Rodrigues

Send a report that this bug log contains spam.