The mailing list for listmasters using Sympa

[Matt Taggart <address@concealed>]

On 3/22/24 02:55, Antonio Casado (via en Mailing List) wrote:
> Hi Sebix,
>
> Nothing about memory in /var/log/messages
> If I restart sympa service, all work ok.

You say "from time to time" and also that restarting fixes it. For how 
long? Also if you have any sort of system monitoring and graphing 
software, being able to look at memory and process graphs would probably 
help a lot.

Have you adjusted bulk_max_count or related in sympa.conf?
Does your system have enough cores and ram?
Is your database on the same system? Have you tuned it?
How many lists/subscribers do you have?

The main cause of bulk.pl crashes I have seen was related to failures in 
parsing certain UTF8 messages, but I think all those bugs got fixed, I 
haven't seen a crash in years. In those cases bulk.pl would repeatedly 
crash each time you restarted until you got rid of the problem message. 
In your case, if a restart fixes it that is more tricky because you 
don't have a reliable way to repeat the problem.

But it could still be something about particular messages causing it. 
Maybe look for patterns in the logs around the time of the crashes, like 
is it always the same sender or list? Particular encoding or 
attachments, etc.

If it does crash shortly after start, the same process to narrow it down 
is something like:

* Look to see which spool dirs have a bunch of messages and inspect
* If you find a backlog, move the messages aside temporarily and see if 
that causes sympa to start and not crash
* If that works, bisect by moving half the messages back, test, adjust, 
iterate. In addition to halving the messages, usually bulk.pl manages to 
process some before it gets to the bad one and the spool gets smaller.
* If you manage to narrow it down to a message that repeats the problem, 
search the bug tracker/file a bug.

--
Matt Taggart
address@concealed