[Mailman-Developers] Faulty Member Subscribe/Unsubscribes

[Andrew Case]

My configuration:
  Mailman: 2.1.14
  OS: Solaris 10
  Python: 2.4.5
  PREFIX = '/usr/mailman'
  Server setup: 1 server for web management, 1 server for MTA/qrunner. 
/usr/mailman is NFS mounted on both servers


I've been having the following issue my mailman lists:

A user is either subscribed or unsubscribed according to the logs, but
then if I look at the member list, the action has not been done (or has
been undone).  For example, here is where I remove a subscriber and then
look at the list members and they are still in the list:

[mailman at myhost] ~/logs |> grep testlist subscribe | grep acase
Sep 28 17:15:14 2011 (4401) testlist: new acase at example.com, admin mass sub
Sep 28 17:19:36 2011 (5821) testlist: deleted acase at example.com; member
mgt page
[mailman at myhost] ~/logs |> ../bin/list_members testlist | grep acase
acase at example.com
[mailman at myhost] ~/logs |>

The same also happens when subscribing.  I will mass subscribe users (or
when users confirm subscription via email/web), the logs indicated that
they have been subscribed successfully, but then when I go look them up,
they are not listed on the members list.

This happens sporadically, but I am generally able to reproduce the error
if I do it a couple times in a row.

I'm suspicious there may be a locking issue and config.pck is reverting to
config.pck.last.  I found this thread rather helpful in analyzing
potential problems, but I have yet to figure anything out:
  http://web.archiveorange.com/archive/v/IezAOgEQf7xEYCSEJTbD

In addition if I just run the following commands over and over, then the
bug never seems to come up.  This is part of why I am worrying about
locking:
  bin/add_members ...
  bin/remove_members ...

Is there a good way to test locking between servers?  I've run the
tests/test_lockfile.py, but it reports it is OK.

Any and all help would be GREATLY appreciated.  We've been trying to
triage this bug for weeks and it is terribly disruptive for our users.

Thanks,

--
Drew