Asterisk spawning multiple processes on incoming calls

Hi

I have a problem with asterisk spawning multiple zombie processes whenever the sales queue recieves an incoming call.

I can kill these processes without an issue, but they are eating up memory on my box.

Does anyone have any idea.

Thanks.

[root@asterisk1 ~]# ps -ef | grep /usr/sbin/asterisk
asterisk 3269 3227 4 03:01 ? 00:28:49 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28654 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28657 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28658 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28659 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28660 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28661 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28662 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28663 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28664 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28666 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28667 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28668 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28669 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28670 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28671 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28672 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28673 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28674 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
asterisk 28675 3269 0 14:13 ? 00:00:00 /usr/sbin/asterisk -U asterisk -G asterisk -vvvg -c
root 29178 16436 0 14:16 pts/0 00:00:00 grep /usr/sbin/asterisk

Is this Asterisk or Asterisk@Home.

Have a read of cyber-cottage.co.uk/site/ind … &Itemid=34
the bit that will be of interest is in the last but one chapter, But basicly using agi proceses will spawn a new process for each agi call.

Ian

Thanks for that. I’m using asterisk@home. I know that it’s not the best thing to use but i’m a newbie who was forced to set up a production system from scratch very quickly.

It does seem like it’s these agi processes that are not terminating cleanly, but i’m not sure of the best way to troubleshoot them

Fortunately although I know nowt about VOIP, I do know a little about UNIX!

I have written the following script to automatically kill the child processes:

#!/bin/sh
ps -ef | grep /usr/sbin/asterisk
for parent in ps -ef | grep safe_asterisk | awk '$3 == '1'{print $2}'
do
echo Checking for parent Asterisk processes started under $parent
for ppid in ps -ef | awk '$3 == '${parent}' { print $2 }'
do
echo Checking for child Asterisk process started under $ppid
for i in ps -ef | awk '$3 == '${ppid}' { print $2 }'
do
echo killing $i
kill -9 $i
done
done
done

So I can cron this if necessary on a regular basis, once tested.

Are these proceses sticking around after the call has ended ? as they wont end till the call ends.

I think you need to look at whats actualy happening? IE how many phones are there in the sales queue, and more importantly how many on the system.
Perhaps a redesign not using AGI may be a good idea.

I personaly would not want a cron job killing child proceses may be there by design.

Ian

Unfortunatly there are a BUTTLOAD of bugs with queues and agents, chacking the asterisk bugtracker.

Im not sure if these Zombies are sposed to be there or not.

What i DO know is, that asterisk is running out of ressources under certain conditions and call loads which makes reboot-crons needed all XY days.

This isnt valid for EVERYONE, its happening under certain conditions, but not clear yet WHAT conditions.

Its filed in their bugtracker already.