| Summary: | ASTERISK-06771: zap restart without asterisk restart | ||
| Reporter: | Tzafrir Cohen (tzafrir) | Labels: | |
| Date Opened: | 2006-04-13 08:50:02 | Date Closed: | 2006-04-27 13:54:09 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_zap |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) zap_restart.diff ( 1) zap_restart.dpatch | |
| Description: | Currently the "reload" action of chan_zap is limited to changing features of existing channels. Adding/removing a channel requires restarting Asterisk. However all the components needed to reload new channels from zapata.conf seem to be there. This patch adds a CLI action called "zap restart" that explicitly destroys all existing zaptel channels and then re-reads zapata.conf as in a normal startup: zap_setup(0) , rather than zap_setup(1) as in a normal reload. ****** ADDITIONAL INFORMATION ****** The patch is against 1.2.7 . I'll provide a patch against trunk soon. Anyway, the patch itself is pretty simple. Due to colissions with other patches this patch does not include a manager action for ZapRestart. The function is there: just the registration is missing. (I know it says "SVN/1.2". It's just that there is no "1.2.7" in Version yet) | ||
| Comments: | By: Tilghman Lesher (tilghman) 2006-04-13 09:27:42 The command help needs a little more description, including a notification that this command will drop any calls currently in progress which are using a Zap channel. Also, if there are any errors in the configuration file, this command could leave ALL Zap channels in a disabled state, whether or not the error was with that particular channel config. Given that most reconfiguration of Zap requires running ztcfg while the channels are not in use, this is a pretty heavy-duty operation that probably misses the most common case of why someone might need to do a zaptel restart: to add channels that were previously not configured on the kernel module level. This is why we've been comfortable simply with a reload action that doesn't reconfigure the channel signalling. By: Tzafrir Cohen (tzafrir) 2006-04-13 10:22:03 Thanks for the feedback. I'll update the help text. However one should not be too surprised if misconfiguration leads to missing channels: the same issues can cause you to lose all of your sip/iax configuration on reload. This code does not run ztcfg. Running ztcfg should be done beforehand. And there should be no problem with re-configuring a channel to its existing configuration. At least not with my tests. I wish to stress that this is not intended to replace the default reload operation. Rather, it requires running explicitly. By: Tzafrir Cohen (tzafrir) 2006-04-13 13:25:20 zap_restart.diff: A patch against trunk (rev. 19767) . The previous patch applied to head as well. * Registered in the manager interface * Changed the help text. By: Andrey S Pankov (casper) 2006-04-16 11:32:28 What about: zap restart gracefully Restart gracefully zap restart now Restart immediately zap restart when convenient Restart at empty call volume ? By: Tzafrir Cohen (tzafrir) 2006-04-16 12:04:23 That could be nice, but can also complicate the patch. e.g: more chances of ugly locking problems. I first want to get the basic functionality in. But if others find such commands highly useful I'll try to add them. By: Matt O'Gorman (mogorman) 2006-04-27 13:54:08 Committed revision 22932. now go add other features like graceful etc | ||