|Summary:||ASTERISK-03704: AGI scripts defunct after exit (in FC3 only)|
|Date Opened:||2005-03-18 16:14:01.000-0600||Date Closed:||2011-06-07 14:09:59|
Running a ps -A, shows a lot of agi scripts in defunct state
|Comments:||By: Clod Patry (junky) 2005-03-18 16:16:00.000-0600|
Are you sure isn't a problem with your AGI? can you attach it?
By: Brian West (bkw918) 2005-03-18 16:16:51.000-0600
By: hassan (hassan) 2005-03-18 16:19:08.000-0600
agi = agilib.AGI()
dnis = agi.env['agi_extension']
ani = agi.env['agi_callerid']
clid = agi.env['agi_callerid']
chan = agi.env['agi_channel']
calldata = "calldata=%s,%s,%s,%s" % (chan, dnis, ani, clid)
#action = agi.verbose(calldata, 1)
request = urllib2.Request('xxxx', data=calldata)
opener = urllib2.build_opener()
queue_name = opener.open(request).read()
action = agi.appexec('SetAccount', options=dnis)
action = agi.appexec('SetCDRUserField', options=queue_name)
action = agi.verbose(message=dnis, level=1)
action = agi.verbose(message=queue_name, level=3)
action = agi.goto_on_exit(queue_name, 's', '1')
action = agi.verbose("exiting script----- call_uuid", level=3)
By: hassan (hassan) 2005-03-18 16:36:02.000-0600
DEADAGI didn't help.
By: Tilghman Lesher (tilghman) 2005-03-18 17:41:53.000-0600
In all likelihood, the default action for python for the HUP signal is to ignore it. What you need to do is install a signal handler for the HUP signal and shut down your process when that signal is received.
This is a bug in your script, not in Asterisk.
By: hassan (hassan) 2005-03-18 17:49:53.000-0600
We had no problems with FC2 and this script. In fact, this script has been running for a while.
A defunct process (or, less formaly, "Zombie", that's the source of
the "Z" state you see in ps) is a process which exit(2)'ed or was killed
but its parent haven't executed a wait(2) on it.
Second, the python agilib for python is used by a lot of developers, i doubt that's the problem.
In all likelihood, res_agi should be tested with FC3
By: Tilghman Lesher (tilghman) 2005-03-19 00:31:10.000-0600
Well, I think you've isolated the problem, and it obviously isn't Asterisk... It's FC3. Unless you can show that something was particularly wrong with how Asterisk handles catching child processes, I'd say this does not need to remain open.
By: hassan (hassan) 2005-03-19 00:37:55.000-0600
You're right, one option would be to go back to FC2. But since progress means moving forward. I think it is worthwhile investigating this problem against the new kernel in FC3. I am sure that this problem will arise again when more releases adopt the new kernel.
By: Tilghman Lesher (tilghman) 2005-03-19 01:11:07.000-0600
You're ducking the issue: it's not that Asterisk is handling the reaping of child processes the wrong way. It's that FC3 has a bug (possibly within its C library) that prevents zombies from being properly reaped.
Unless you can show an actual bug in Asterisk in regards to this, I'm going to close this report, as it is not a bug in Asterisk.
By: Mark Spencer (markster) 2005-03-19 11:32:44.000-0600
If it works with FC2 and doesn't work with FC3, what makes you suspect this is a bug in Asterisk?