Massimo Lanfranconi wrote:
I am more than willing to try any workaround as this bug is currently a showstopper for my project. I am not very versed in mailman internals, so I need some guidance here.
Do you recommend I try getting rid of the __timestamp test and give it a try ?
Yes.
If that is you suggestion, may I ask what was the original purpose of that test ?
Lots of Mailman processes will instantiate a list unlocked for some preliminary checks and then later, lock the list to do some update. The purpose of the timestamp test was to avoid rereading the list data from the config.pck file if the already loaded data is still current.
What I suggest for the moment is to just delete lines 594-603 of Mailman/MailList.py which includes the following 4 lines and the preceding comment.
mtime = os.path.getmtime(dbfile) if mtime <= self.__timestamp: # File is not newer return None, None
This will result in some additional I/O in some cases, but it will avoid this problem of sometimes not loading the list data when it has actually changed.
Please do that and restart Mailman and I'm sure the bug will be fixed (but don't take my word for it).
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan