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