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.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to