I had a strange occurrance yesterday on one of my lists

Mailman 2.1.10 Python 2.4.3 CentOS release 5 (Final)

PREFIX = '/usr/local/mailman' VAR_PREFIX = '/var/lib/mailman'

/usr/local/ and /var/ are separate partitions on the same local disk. Access is strictly local; no NFS or anything like that.

What happened is a user was logged in to her options page. She was going on vacation, so she first changed her password, but then she was confused and instead of disabling mail delivery, she unsubscribed. A notice of the unsubscribe was sent to the list admin and to her, and the unsubscribe via the member options page was logged, but later, she was still on the list with the new password. There was no log or notice of any new subscribes, and the rest of the list members were the same so no address was changed to her address.

There was a list post being processed at the same time. In fact, it appears that the post was approved from the list's admindb interface about 1 second earlier than the unsub from the member options page.

I've looked over the code and I can't see anywhere where list data are manipulated without being locked, and besides calling the Save() method on an unlocked list throws an exception and locking a list refreshes current data from config.pck, so it should not be possible for two processes to be updating the list concurrently unless there is some issue in LockFile itself.

There's nothing in Mailman's locks log, and grep of all the system logs for 'listname.lock' finds nothing either.

Has anyone seen anything like this?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan