[Bug 1077908] [NEW] MailList configuration race condition between qrunners
jkaluza at redhat.com
Mon Nov 12 13:22:48 CET 2012
Public bug reported:
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.
** Affects: mailman
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
MailList configuration race condition between qrunners
To manage notifications about this bug go to:
More information about the Mailman-coders