[Bug 1077908] [NEW] MailList configuration race condition between qrunners

Jan Kaluza 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
     Importance: Undecided
         Status: New

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 mailing list