The mailing list for listmasters using Sympa

[Miles Fidelman <address@concealed>]

On 10/30/18 3:53 AM, Stefan Hornburg (Racke) wrote:

> On 10/29/18 7:39 PM, Miles Fidelman wrote:
> > Hi Folks,
> >
> > I'm having a problem - hopefully somebody might have some ideas.
> >
> > Sympa 6.1.20, with postfix, amavisd, clamav.
> >
> > On rare occasion, sympa.pl will die, and do so repeatedly after attempting to 
> > restart all the sympa processes.
> >
> > In the past, the cure has been simple - stop all the processes, empty the 
> > queues (almost there's some message that is
> > making something barf), kill any wwsympa tasks running, restart apache, 
> > restart sympa.
> >
> > This time, it's not working - ques are flushed, stop everything, a sympa.pl 
> > process is still running (even though sympa
> > status says it died), kill the process, then restart.  Sympa.pl immediately dies 
> > again (status shows "sympa died, pid
> > file remains.".  Nothing in the log that shows anything wrong.
> >
> > Any suggestions as to:
> >
> > - things that might cause sympa.pl to die abnormally?
> >
> > - any diagnostic tricks (higher log levels, where to set them, etc?)
> >
> > Thanks very much!
> >
> > Miles Fidelman
> Hello Miles,
>
> is there any clue in the logs why Sympa dies? It would also worth to examine 
> the messages that let barf Sympa.
>
> If if says PID file remains, it is stale and you may need to remove it.
>
> Also what is your system setup? Linux distribution? Installed from source or 
> package?
>
> Regards
>          Racke

The log is useless, even at log level 4.  Running at the command line, 
in debug mode, output just stops while Sympa starts eating a majority of 
cpu cycles.  Nothing in the log indicates an error, or where things are 
hanging.

The best I can do, without starting to seriously spelunk the code base 
is to identify this series of repeating log messages, just before sympa 
stops writing anything at all to the log.

Oct 29 18:43:43 server1 sympa[19280]: debug2 mail::reaper() Reaper 
unwaited pids
 : #012Open = 0
Oct 29 18:43:48 server1 sympa[19280]: debug2 Language::SetLang() 
Language::SetLa
ng(en_US)
Oct 29 18:43:48 server1 sympa[19280]: debug2 List::init_list_cache() 
List::init_
list_cache()

What module is generating the messages, or what message it's working on, 
isn't indicated.

In the past, it seems like this  happens when some specific message 
chokes something - clearing the msg spool fixes things.  This time it 
didn't.  This time I had to rm everything, in every spool directory 
(including tasks), and /tmp for good measure.  Then things went back to 
normal (modulo a days worth of messages, and a few digests that never 
made it out).

It would be kind of nice if sympa logged messages & tasks, as it 
processes them - so that such things can be tracked down. ("starting to 
process msg-id xxxx").  (Maybe it does, but not to syslog.)

Any suggestions for next time, still welcomed.

Sigh...

Thanks,

Miles Fidelman





--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra