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

Category: command line scripts Group: 2.1 beta

Status: Closed Resolution: Fixed 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: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:51

Message: Logged In: YES user_id=12800

Thanks! I'm going to fix this in a slightly different way, but your patch definitely paved the way.

Comment By: E. Viennet (anotong) Date: 2002-07-07 03:26

Message: Logged In: YES user_id=396722

I also observed this behavior.

I did patch my mailman (mailmanctl, acquire_lock_1) by putting try/except pairs around each call to unlink(), but I'm not sure it's the correct fix.

Comment By: Dale Stimson (dstimson) Date: 2002-06-07 14: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: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103