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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
