[mythtv-commits] Ticket #3248: mytharchive lockfile issues

[MythTV]

#3248: mytharchive lockfile issues
-------------------------+--------------------------------------------------
 Reporter:  anonymous    |       Owner:  paulh  
     Type:  defect       |      Status:  new    
 Priority:  minor        |   Milestone:  unknown
Component:  mytharchive  |     Version:  0.20   
 Severity:  medium       |  
-------------------------+--------------------------------------------------
 I posted this the mythtv-dev list on 2007 Mar 5
 http://mythtv.org/pipermail/mythtv-dev/2007-March/054076.html
 (Trac didn't accept new tickets at that time).

 There was no posted response but on 2007 March 18 paulh submitted
 changeset 13070 that addressed most of these concerns.

 I'm adding this ticket record the issues and comment on the changeset.

 Verbatim from email to list:

 ----

 mytharchive has been acting up on me, so I did some investigation.

 Sometimes a mythburn step fails (I'm vague on how or what), leaving the
 mythburn.lck lock file but no mythburn.py process.  When this happens,
 cancel requests are ineffective, and any attempt to archive something
 just gets you into the logviewer program, whatching the log make no
 further process.  Nothing will ever delete the lock.

 For example, we tried to put too much on a DVD and got into that
 state.

 So there are two problems:
 (1) a failure with no proper diagnostic or termination
 (2) and then no way to archive after this.

 This message was prompted by investigation of problem 2.

 I'm not the only one to have experienced this.  See, for example
 http://threebit.net/mail-archive/mythtv-users/msg35922.html


 The mythburn.lck lockfile logic in mythburn.py has a few problems.

 - The checking for and creation of a lock ought to be "atomic".
   Otherwise there can be a race condition.  The conventional way of
   doing this on UNIX-like systems is to try to creat a lockfile
   using, in Python terms,
         os.open(lockfilepath, O_WRONLY | O_CREAT | O_EXCL)
   If there is already a lockfile, this fails
   Otherwise, it creates one.
   This is atomic.

 - the logic of mythburn.py's try ... finally block at lines 3571
   through 3611 seems wrong.  The finally part removes the lock file
   but it may not belong to this process.  Luckilly, the program that
   invokes mythburn.py will not do so if the lock is present.  So this
   case will not come up.  Still, this seems quite wrong.

 - the lock file, when present, simply contains the string "lock".  It
   is better to follow the convention that the lock file contains the
   process ID of the owning process.  This allows people and processes
   to determine if a lock is stale: held by a now-dead process.

 - It seems to me that each place where the lock is checked should then
   check to see if the lock is stale and act accordingly (break the
   lock if stale, perhaps with a warning).

 Once this last step is implemented, my problem 2 will go away.

 I started to code changes to mythburn.py but before getting serious,
 I'd like to know if the relevant authorities think I'm on the right
 track.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/3248>
MythTV <http://svn.mythtv.org/trac>
MythTV