+++ This bug was initially created as a clone of Bug #517321 +++
Description of problem (from Bug #517321):
"Job 'cron.daily' locked by another anacron - skipping". As a result logwatch cannot deliver. This has been reported before and closed without remedy but remains a problem.
For further details please see Bug #517321,
I've come across this because of Bug #722209, which effectively details why the "solution" implemented for Bug #517321 is wrong.
Version-Release number of selected component (now):
failure to run cron.daily
In a reply to comment #4 of Bug #722209 I've outlined a possible fix for the run-parts command of the crontabs package.
No, the scripts run from the cron.* should simply not be long-running. And if they are, they should correctly daemonize including redirecting their std* descriptors.
This is not a bug.
(In reply to comment #1)
> No, the scripts run from the cron.* should simply not be long-running. And if
> they are, they should correctly daemonize including redirecting their std*
> This is not a bug.
Well, logrotate itself is not a long-running process. The problem comes from some daemons restarted by other scripts from other packages, used by logrotate.
In the same way you say this is not a bug of run-parts, the logrotate maintainers could say that this is a bug of the other package that provided the script to restart that daemon.
I'd clearly prefer a solution at the root of the problem, which is the run-parts command, IMHO, prefering robust behaviour over formal principles of how to start daemon processes.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
No, that's surely true that in this case the bug is not even in the logrotate. The bug is in the third party package's logrotate script or in the daemonization implementation in the third party package.
And no, your proposal to redirect to a file is not correct really - the file will be kept on the disk (even after unlinking) until the daemon exits and it could eventually fill up the free space if the daemon decides to write bogus data into it.
This is really notabug in both crontabs and logrotate and it MUST be fixed at the right place - that is where the file descriptors are leaked.