[Mailman-Developers] [ mailman-Bugs-565917 ] mailmanctl bombs after unclean shutdown

[noreply@sourceforge.net]

Bugs item #565917, was opened at 2002-06-07 18:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103

Category: command line scripts
Group: 2.1 beta
Status: Open
Resolution: None
Priority: 5
Submitted By: Dale Stimson (dstimson)
Assigned to: Nobody/Anonymous (nobody)
Summary: mailmanctl bombs after unclean shutdown

Initial Comment:
Environment: Red Hat 7.3, latest errata, Mailman 2.1b2 

I see that this problem still exists in the current CVS
as of
a day or two ago.

When mailman restarts after having been shutdown
uncleanly (e.g.,
when rebooting following a crash), it bombs leaving no
qrunners
active with the following in the log:

Jun 04 18:05:13 2002 mailmanctl(1572): Traceback (most
recent call last):
Jun 04 18:05:13 2002 mailmanctl(1572):   File
"/var/mailman/bin/mailmanctl", line 502, in ?
Jun 04 18:05:13 2002 mailmanctl(1572):      main()
Jun 04 18:05:13 2002 mailmanctl(1572):   File
"/var/mailman/bin/mailmanctl", line 352, in main
Jun 04 18:05:13 2002 mailmanctl(1572):      lock =
acquire_lock(force)
Jun 04 18:05:13 2002 mailmanctl(1572):   File
"/var/mailman/bin/mailmanctl", line 203, in acquire_lock
Jun 04 18:05:13 2002 mailmanctl(1572):      lock =
acquire_lock_1(force)
Jun 04 18:05:13 2002 mailmanctl(1572):   File
"/var/mailman/bin/mailmanctl", line 197, in acquire_lock_1
Jun 04 18:05:13 2002 mailmanctl(1572):     
os.unlink(tempfile)
Jun 04 18:05:13 2002 mailmanctl(1572): OSError : 
[Errno 2] No such file or directory:
'master-qrunner.cupro.opengvs.com.9014'


Diagnosis: In file bin/mailmanctl, function
acquire_lock_1 is 
attempting to delete the lock file left over from the
last run.
It calls function get_lock_data to find the name of the
old lock
file that is to be deleted.  Function get_lock_data
(incorrectly)
returns the file name with the directory part of the path
stripped, thereby causing the delete to fail and the
trap to occur.
Function get_lock_data should instead return the entire
file path,
including directories.  The patch given below corrects
the behavior
of get_lock_data.

As an aside, it would be nice if acquire_lock_1 was
more forgiving if
the os.unlink calls fail due to "no such file".  I have
not submitted
a patch for that as I don't know the appropriate python
semantics.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103