Bug 742206 - Job 'cron.daily' locked by another anacron - skipping
Summary: Job 'cron.daily' locked by another anacron - skipping
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: crontabs
Version: 6.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Marcela Mašláňová
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-29 11:44 UTC by Robert Vogelgesang
Modified: 2017-12-04 12:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 517321
Environment:
Last Closed: 2011-09-29 12:45:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Robert Vogelgesang 2011-09-29 11:44:04 UTC
+++ 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):
crontabs-1.10-8 (RHEL-5)
crontabs-1.10-32.1.el6 (RHEL-6)

Actual results:
failure to run cron.daily

Additional info:
In a reply to comment #4 of Bug #722209 I've outlined a possible fix for the run-parts command of the crontabs package.

Comment 1 Tomas Mraz 2011-09-29 11:53:30 UTC
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.

Comment 3 Robert Vogelgesang 2011-09-29 12:15:11 UTC
(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*
> descriptors.
> 
> 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.

Comment 4 RHEL Program Management 2011-09-29 12:18:52 UTC
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
representative.

Comment 5 Tomas Mraz 2011-09-29 12:45:31 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.