Skip to Content.
Sympa Menu

en - Re: [sympa-users] task_manager.pl gone wild since blackout

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Tornóci László <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-users] task_manager.pl gone wild since blackout
  • Date: Tue, 31 Jul 2012 21:18:27 +0200

On 07/31/2012 05:37 PM, Tornóci László wrote:
Hi,

I have been running sympa for a few years now without major problems
(currently using 6.1.7 on RHEL 6.3). There was a blackout on July 25,
the server suddenly lost electricity then later restarted. Since then
task_manager.pl takes 98% of CPU, and consumes more and more RAM to the
point that it consumes all, and the system will kill the process. This
happens all the time I restart sympa. I have about 160 tasks in
sympa/spool/tasks, their dates are mostly July 25. I tried to remove all
tasks from sympa/spool/tasks (stopped sympa, moved all the files to
another dir, then restarted sympa) but that didn't change anything. So I
guess the problem is not the tasks themselves.
There is nothing special in the logs (/var/log/messages):

In the meantime I managed to solve this problem. First I tried to start task_manager.pl by hand with the options -d -F. No output except the usual:
task_manager.pl: notice tools::write_pid() Previous process 17702 died suddenly ; notifying listmaster
and the process started to eat RAM.

Then I killed the process, deleted the sympa/task_manager.pid and started again: an voila task_manager flooded the screen with output, RAM consumption remained reasonable and the tasks in sympa/spool/tasks got handled correcly and replaced with future tasks.

Right now I cannot reproduce the problem. A stale pid file alone won't trigger the problem. Looks like you need a combination of tasks in sympa/spool/tasks that are past deadline AND a stale pid file present to trigger the problem I described. I managed to have this combination because of the blackout period. However, it is really bad behaviour, that I encountered. I definitely suggest the developers review the code.

Another problem I've had and fixed, that syslog logging was set to LOCAL1 in /etc/sympa.conf, but LOCAL1 was not defined in /etc/rsyslogd.conf. I don't know if this may have contributed to the problem I had.

Yours: Laszlo




Archive powered by MHonArc 2.6.19+.

Top of Page