Summary:	ASTERISK-10562: [patch] zap restart fails to generate channels
Reporter:	Tzafrir Cohen (tzafrir)	Labels:
Date Opened:	2007-10-17 15:50:11	Date Closed:	2008-08-21 18:30:40
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_zap
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zap_restart.diff
Description:	The command "zap restart" has been added before 1.4 . However at some point it has been changed to run setup_zap(2) instead of setup_zap(0) . This makes it useless, as it can only destroy channels and not create new ones. The attached patch fixes this, as well as other implementation issues with zap_restart: * Just release all the interfaces at once. The same code as in the module unload. * Thus we also lock the iflist when destroying channel. * If we were listening on some file descriptors and now we don't, pfds was still pointing to a value even though its value has been released. With this patch a restart of analog channels work. A restart of digital spans still fails, as there is no where in the code that D channels are being released. ****** ADDITIONAL INFORMATION ****** Note that the standard channel destruction command ("zap destroy channel NNN") does not lock the interfaces list as well.
Comments:	By: Jason Parker (jparker) 2007-11-01 12:35:47 I committed the pfds = NULL fix to 1.4 and trunk. I'm slightly concerned about the sleep().  It seems like somewhat of a hack.  What is the reason it is needed? By: Tzafrir Cohen (tzafrir) 2007-11-01 12:46:06 The sleep() hack seems to require some more debugging at the zaptel level, I guess. By: Kevin P. Fleming (kpfleming) 2008-01-11 17:57:02.000-0600 What symptoms did you see without the sleep() in place? By: Tzafrir Cohen (tzafrir) 2008-01-11 18:09:50.000-0600 The channels are busy. In that case running 'zap restart' twice would do the trick. Again, this is the case of non-PRI channels only. In the case of PRIs, the D channel is never properly closed. And will never be properly re-initialized. By: jmls (jmls) 2008-02-06 04:30:25.000-0600 tzafrir, is this still a problem ? By: jmls (jmls) 2008-02-17 14:41:45.000-0600 Housekeeping ... ping ... By: Digium Subversion (svnbot) 2008-08-15 14:13:13 Repository: asterisk Revision: 138119 U   branches/1.4/channels/chan_dahdi.c ------------------------------------------------------------------------ r138119 | jpeeler | 2008-08-15 14:13:11 -0500 (Fri, 15 Aug 2008) | 4 lines Fixes the dahdi restart functionality. Dahdi restart allows one to restart all DAHDI channels, even if they are currently in use. This is different from unloading and then loading the module since unloading requires the use count to be zero. Reloading the module is different in that the signalling is not changed from what it was originally configured. Also, this fixes not closing all the file descriptors for D-channels upon module unload (which would prevent loading the module afterwards). (closes issue ASTERISK-10562) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=138119 By: Tzafrir Cohen (tzafrir) 2008-08-21 11:45:03 Apologies for not testing it well enough before. I have just noticed the following issue: there is a potentially endless loop when running 'dahdi restart': while (tmp->subs[SUB_REAL].dfd < 0 && reloading == 2) { /* the kernel may not call dahdi_release fast enough for the open flagbit to be cleared in time */       usleep(1);       tmp->subs[SUB_REAL].dfd = dahdi_open(fn); } What happens if the channel is kept busy by something else? * Another Asterisk instance? * A bug that causes a channel not to get closed? * any other program? To reproduce: asterisk -rx 'dahdi destroy channel 1' cat </dev/dahdi/1 >/dev/null & asterisk -rx 'dahdi restart' By: Digium Subversion (svnbot) 2008-08-21 18:30:36 Repository: asterisk Revision: 139387 U   branches/1.4/channels/chan_dahdi.c ------------------------------------------------------------------------ r139387 | jpeeler | 2008-08-21 18:30:35 -0500 (Thu, 21 Aug 2008) | 3 lines Fixes loop that could possibly never exit in the event of a channel never being able to be opened or specify after a restart. (closes issue ASTERISK-10562) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=139387