Summary:	ASTERISK-19533: Script run from #exec can't connect to the manager on initial start or restart of Asterisk
Reporter:	Philippe Lindheimer (p_lindheimer)	Labels:
Date Opened:	2012-03-13 13:28:47	Date Closed:	2015-04-29 11:19:03
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Codecs/General
Versions:	1.8.8.2 10.2.0	Frequency of Occurrence
Related Issues:
Environment:	Detected on FreePBX but general issue	Attachments:
Description:	Trying to open up an AMI connection from a #exec script in the dialplan fails upon Asterisk starting or restarting. It works other times. This mechanism is used to generate hints in the dialplan based on dynamic information that is only available in the AstDB and on all releases at least 1.8 and prior going into the manager is the only way to get such information. I have tested that this fails on 1.4.22-ish (and SVN build about that time), 1.4.32, 1.8.8.0, 10.2.0. As such I have said "No" to it being a regression though I believe at some point probably prior to 1.4.22 this may have worked. It may have been in 1.2?
Comments:	By: Matt Jordan (mjordan) 2012-03-19 08:48:54.392-0500 Are you waiting until Asterisk is fully booted before attempting the connection?  You should be able to use the "core waitfullybooted" command to determine when Asterisk is fully up and running. By: Philippe Lindheimer (p_lindheimer) 2012-03-19 10:04:36.753-0500 waiting for Asterisk to be fully booted is not really an option, this is part of a #exec script executed from extensions.conf, in order to execute that command we would have to make a manager connection to send the command but the manager connection is what fails in this case. By: Matt Jordan (mjordan) 2012-04-02 15:30:54.154-0500 Please use the "Send Back" button to send this back to a bug marshal.  Otherwise, the notification that you entered feedback is typically lost. You don't have to use a manager command to perform a "core wait fully booted" - you could use a remote Asterisk execution of a CLI command.  We do something similar in the Asterisk Test Suite - we periodically poll Asterisk for up to a particular timeout in order to determine when it is fully up and able to receive an AMI connection. By: Philippe Lindheimer (p_lindheimer) 2012-04-02 17:49:05.833-0500 Matt, I don't think you are understanding the flow or otherwise I don't understand your point The #exec is in extensions.conf. When we start Asterisk, extensions.conf gets read. We can't wait until it's started before having to have it load extensions.conf, that is part of Asterisk starting. At best, I could start Asterisk, let this failure occur and do a 'wait until fully booted' and then send it a core reload to re-read the dialplan thus properly executing the #exec correctly the next time. However, that is a workaround to this bug since the first time the #exec fails. By: Philippe Lindheimer (p_lindheimer) 2012-04-02 17:49:39.593-0500 Sending my comment back to bug marshal per Matt's comment, hope I'm doing this right. By: Matt Jordan (mjordan) 2012-04-03 08:36:25.106-0500 Philippe: Yup, the button worked just fine :-) Thanks for the clarification on the workflow - that makes more sense now. Technically, the manager initialization occurs before dialplan load, but its possible that it isn't quite ready for connections by the time the dialplan has processed.  I'll move this issue forward, but do you mind attaching a DEBUG log illustrating the problem? Thanks Matt By: Corey Farrell (coreyfarrell) 2015-03-29 14:43:36.113-0500 Is this still an issue in currently supported branches?  If so can you provide the DEBUG logs [~mjordan] requested?  Also please provide your {{modules.conf}} Based on what I see in the code, the AMI listening socket is opened from the main thread, meaning that AMI is listening for clients before init_manager() returns. The possible explanation I see for this is if you have pbx_config set to preload in {{modules.conf}}.  This will not work as preload modules are started before AMI.  If this is the case you will need to either remove the preload setting from pbx_config, or not use AMI during its load. By: Matt Jordan (mjordan) 2015-03-29 20:42:22.566-0500 [~coreyfarrell]: I know FreePBX used to preload {{pbx_config}} when the issue was first filed. IIRC, it was to ensure that device states for Local channel members would be available - I vaguely recall that unless you do that in older versions of Asterisk, they won't be. [~p_lindheimer] would certainly know for sure :-) By: Andrew Nagy (tm1000) 2015-04-29 10:50:33.794-0500 Previously. In some initial alpha build of Asterisk 12 preloading pbx_config would crash Asterisk. [~mjordan] fixed this and said that pbx_config no longer needed to be preloaded. Possibly as far back as 1.8... however I am not sure. In FreePBX we still preload pbx_config on first install. By: Rusty Newton (rnewton) 2015-04-29 11:18:32.313-0500 Thanks. Sounds like we can close this out then. If something changes and we need to re-open, let us know.