[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.



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

>Comment By: Dale Stimson (dstimson)
Date: 2002-06-07 18:14

Message:
Logged In: YES 
user_id=559033

Please ignore uploaded file sf1.txt (it won't let me delete
it), which has cruft in it (the problem report text), as
opposed to just the patch).  The file with just the patch is
sf.txt.

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

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