RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 2021-03-11 14:10 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:
Embargoed:

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.