Bug 875453 - yum-cron: stale lock dir is not catched - resulting in no execution
yum-cron: stale lock dir is not catched - resulting in no execution
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: packaging-team-maint
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2012-11-11 06:11 EST by Peter Bieringer
Modified: 2014-01-21 01:25 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-03-18 12:27:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2012-11-11 06:11:54 EST
Description of problem:

when a stale lock directory is existing, yum-cron will exit silently instead of execution

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create lock dir /var/lock/yum-cron.lock or kill -9 yum-cron while sleeping
2. Try to run again
Actual results:
Silent exit

Expected results:
Detecting stale lock file

Additional info:

Original behavior:

# ./yum.cron 
+ LOCKFILE=/var/lock/yum-cron.lock
+ '[' '!' -f /var/lock/subsys/yum-cron ']'
+ mkdir /var/lock/yum-cron.lock
+ exit

Such patch will be a fix:
@@ -10,7 +8,7 @@
 # Try mkdir for the lockfile, will test for and make it in one atomic action
-mkdir $LOCKFILE 2>/dev/null || exit
+[ ! -d $LOCKFILE ] && mkdir $LOCKFILE 2>/dev/null || exit
 # and clean up that lockfile if the script exits or is killed  
 trap "{ rmdir $LOCKFILE 2>/dev/null ; exit 255; }" INT TERM EXIT

But a little bit strange that LOCKFILE is actually used as LOCKDIR
Comment 1 Zdeněk Pavlas 2013-03-18 12:27:04 EDT
Yes, there's no test that the lock file is stale.  But Your patch does not seem to fix that.  When there's a stale lock, "[ ! -d $LOCKFILE ]" evaluates to false, so the || exit is evaluated anyway- lock file is not unlinked.

The correct fix should use a lock file, store a pid there, and verify that the pid is valid..  However, it seems difficult to create the stale lockfile, basically you'd have to sigkill a running job.

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