Summary:	ASTERISK-03704: AGI scripts defunct after exit (in FC3 only)
Reporter:	hassan (hassan)	Labels:
Date Opened:	2005-03-18 16:14:01.000-0600	Date Closed:	2011-06-07 14:09:59
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_agi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	FC3 Asterisk 1.0.6 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 Use DEADAGI... /b By: hassan (hassan) 2005-03-18 16:19:08.000-0600 #!/usr/bin/python import agilib import urllib2 import sys 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) sys.exit(1) By: hassan (hassan) 2005-03-18 16:36:02.000-0600 DEADAGI didn't help. Same problem 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?