[asterisk-bugs] [Asterisk 0015189]: [patch] #exec script can't access manager on first asterisk load

Thu Jun 4 09:53:54 CDT 2009

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15189 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                seanbright
====================================================================== 
Project:                    Asterisk
Issue ID:                   15189
Category:                   Core/PBX
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     closed
Target Version:             1.4.26
Asterisk Version:           SVN 
Regression:                 Yes 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 196616 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-05-24 12:32 CDT
Last Modified:              2009-06-04 09:53 CDT
====================================================================== 
Summary:                    [patch] #exec script can't access manager on first
asterisk load
Description: 
In earlier versions of Asterisk (1.4.21.1 tested, also 1.2.x I believe), a
'#exec' directive in extensions.conf can run a script that can then access
the manager which is required to get to ASTDB to obtain information to
generate dialplan.

A fix to bug https://issues.asterisk.org/view.php?id=13778 (revision 151905) has
broken this.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
child of            0013778 asterisk blocked at startup between mai...
====================================================================== 

---------------------------------------------------------------------- 
 (0105980) svnbot (reporter) - 2009-06-04 09:53
 https://issues.asterisk.org/view.php?id=15189#c105980 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 199053

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/_private.h
U   branches/1.6.1/main/asterisk.c
U   branches/1.6.1/main/loader.c

------------------------------------------------------------------------
r199053 | seanbright | 2009-06-04 09:53:54 -0500 (Thu, 04 Jun 2009) | 54
lines

Merged revisions 199051 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r199051 | seanbright | 2009-06-04 10:31:24 -0400 (Thu, 04 Jun 2009) | 47
lines

  Merged revisions 199022 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4

  ........
    r199022 | seanbright | 2009-06-04 10:14:57 -0400 (Thu, 04 Jun 2009) |
40 lines

    Safely handle AMI connections/reload requests that occur during
startup.

    During asterisk startup, a lock on the list of modules is obtained by
the
    primary thread while each module is initialized.  Issue 13778 pointed
out a
    problem with this approach, however.  Because the AMI is loaded before
other
    modules, it is possible for a module reload to be issued by a
connected client
    (via Action: Command), causing a deadlock.

    The resolution for 13778 was to move initialization of the manager to
happen
    after the other modules had already been lodaded.  While this fixed
this
    particular issue, it caused a problem for users (like FreePBX) who
call AMI
    scripts via an #exec in a configuration file (See issue 15189).

    The solution I have come up with is to defer any reload requests that
come in
    until after the server is fully booted.  When a call comes in to
    ast_module_reload (from wherever) before we are fully booted, the
request is
    added to a queue of pending requests.  Once we are done booting up, we
then
    execute these deferred requests in turn.

    Note that I have tried to make this a bit more intelligent in that it
will not
    queue up more than 1 request for the same module to be reloaded, and
if a
    general reload request comes in ('module reload') the queue is flushed
and we
    only issue a single deferred reload for the entire system.

    As for how this will impact existing installations - Before 13778, a
reload
    issued before module initialization was completed would result in a
deadlock.
    After 13778, you simply couldn't connect to the manager during startup
(which
    causes problems with #exec-that-calls-AMI configuration files).  I
believe this
    is a good general purpose solution that won't negatively impact
existing
    installations.

    (closes issue https://issues.asterisk.org/view.php?id=15189)
    (closes issue https://issues.asterisk.org/view.php?id=13778)
    Reported by: p_lindheimer
    Patches:
          06032009_15189_deferred_reloads.diff uploaded by seanbright
(license 71)
    Tested by: p_lindheimer, seanbright

    Review: https://reviewboard.asterisk.org/r/272/
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=199053 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-04 09:53 svnbot         Checkin                                      
2009-06-04 09:53 svnbot         Note Added: 0105980                          
======================================================================