Bug 875453

Summary: yum-cron: stale lock dir is not catched - resulting in no execution
Product: Red Hat Enterprise Linux 5 Reporter: Peter Bieringer <pb>
Component: yumAssignee: packaging-team-maint
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.10CC: zpavlas
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-18 12:27:04 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

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):
yum-cron-0.6-1.el5

How reproducible:
Always

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 @@
 fi
 
 # 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.