Asterisk spawning multiple processes on incoming calls


#1

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


#2

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


#3

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


#4

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.


#5

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


#6

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.