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
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
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
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
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
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
6 matches
Mail list logo