The mailing list for listmasters using Sympa

[Adam Bernstein <address@concealed>]

Sympa team --

We're currently trying to nail down a bug that recently began causing our 
sympa.pl process to quietly stop processing anything until it's restarted. 
 Before I file a bug report, I'm trying to understand better what's 
happening, and we have a few clues but not the whole picture.

One question that will help me figure it out is:  When a digest is sent to 
a list, is sympa.pl supposed to fork a new process?  When our system stops 
working, we're seeing extra sympa.pl processes running, started at the time 
that the digest was sent to a certain list.  I'm wondering if the process 
shouldn't have started at all or if it should have started and then 
terminated.  We're currently running Sympa 5.1.2 with the default process 
profile, ie. one process for both commands and messages.

To describe the problem somewhat more fully:  There seems to be a problem 
related to sending digests, usually (but not always) on one particular 
list, which leaves one or two extra sympa.pl processes running, although 
the digest is sent to all the proper subscribers and the "Digest sent" 
message is logged.  The system then continues working properly, processing 
commands and messages, until some point hours later when sympa.pl stops 
processing anything.  We then sometimes find a mhonarc process running and 
hung, with no corresponding "Archiving..." log entry (which is weird 
because that logging should happen before the call to mail2arc in 
archived.pl), or else we find that the last logged action was a moderator 
giving the "distribute" command on a moderated list, which does not get 
processed until after a process restart.  We kill everything and restart 
sympa, and then all is well.

There may be patterns in the lists that are involved, especially in the 
initial error condition that leaves multiple sympa.pl processes running. 
In the small sample of incidents we've tracked, it's usually a certain 
list, list1@robot1, whose digest led to the hung process, but once it was 
list2@robot1.  There is nothing wrong with the configuration of either list 
or this robot, no recent changes that could account for bad behavior, and 
their digests work fine on some days.

Does this (very long) problem description bring anything to mind?  Should 
we try running with separate processes for commands and messages?  I would 
certainly appreciate any insight.

Thanks!
     adam