Skip to Content.
Sympa Menu

en - Re: [en@sympa] bulk.pl died

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Antonio Casado <address@concealed>
  • To: Matt Taggart <address@concealed>
  • Cc: address@concealed
  • Subject: Re: [en@sympa] bulk.pl died
  • Date: Mon, 25 Mar 2024 10:40:32 +0100

Thanks Matt,

I have seen this about that time of error:
# find /var/spool/sympa -type f -ls | grep ' mar 21 11:5'
69600016    4 -rw-r-----   1 sympa    sympa        1136 mar 21 11:54 /var/spool/sympa/tmp/29500.stderr
69600022    4 -rw-r-----   1 sympa    sympa        1141 mar 21 11:54 /var/spool/sympa/tmp/29501.stderr
69599974    4 -rw-r-----   1 sympa    sympa        1147 mar 21 11:54 /var/spool/sympa/tmp/29503.stderr
2946474  104 -rw-------   1 sympa    sympa      102445 mar 21 11:54 /address@concealed

That information is important?

Regards

El vie, 22 mar 2024 a las 16:54, Matt Taggart (<address@concealed>) escribió:
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




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.19+.

Top of Page