MailList configuration race condition between qrunners
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Mailman |
Incomplete
|
Medium
|
Mark Sapiro |
Bug Description
Hi,
If two qrunner processes access list configuration file in the same second, second qrunner proces does not reload the configuration file, because it thinks that it has not changed. The decision is made according to config file's modification time, which is always in seconds (not in miliseconds) on older systems.
This breaks mlist.post_id incrementation if the first process is IncomingRunner and second process ArchRunner and leads to situation where two emails have the same sequence number.
The flow is following (everything happens in the same second):
AR (ArchRunner) loads config file with post_id=1
AR saves config file with post_id=1
IR (IncomingRunner) loads config file with post_id=1
IR increments post_id and saves config file with post_id=2
AR loads config file, but mlist.__timestamp == mtime, so it thinks it has the latest config file
AR uses post_id=1 (instead of post_id=2)
AR saves config file with post_id=1 (the bug happens - post_id=2 is replaced with post_id=1 in config file)
Second problem is that during the GENERAL_PIPELINE, in some cases the lock file is unlocked and next mlist.Save() fails. The patch checks for this case and try to Lock() the mailing list again.
Changed in mailman: | |
status: | Fix Committed → Triaged |
status: | Triaged → Incomplete |
Hm, when thinking about it, my patch wasn't the best thing for the race-condition. It will load config file everytime now, I think. But I think you got the idea what's wrong there.