[Mailman-Developers]
[ mailman-Bugs-565917 ] mailmanctl bombs after unclean shutdown
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 07 Jun 2002 11:02:50 -0700
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