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 #15189)
  (closes issue #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/
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199051 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 8 insertions, 9 deletions

diff --git a/main/asterisk.c b/main/asterisk.c
index c33702144..a756b305b 100644
--- a/main/asterisk.c
+++ b/main/asterisk.c
@@ -3590,6 +3590,11 @@ int main(int argc, char *argv[])
 
 	ast_channels_init();
 
+	if (init_manager()) {
+		printf("%s", term_quit());
+		exit(1);
+	}
+
 	if (ast_cdr_engine_init()) {
 		printf("%s", term_quit());
 		exit(1);
@@ -3650,15 +3655,6 @@ int main(int argc, char *argv[])
 
 	ast_stun_init();
 
-	/* AMI is initialized after loading modules because of a potential
-	 * conflict between issuing a module reload from manager and
-	 * registering manager actions.  This will cause reversed locking
-	 * order between the module list and manager actions list. */
-	if (init_manager()) {
-		printf("%s", term_quit());
-		exit(1);
-	}
-
 	dnsmgr_start_refresh();
 
 	/* We might have the option of showing a console, but for now just
@@ -3674,6 +3670,9 @@ int main(int argc, char *argv[])
 		sig_alert_pipe[0] = sig_alert_pipe[1] = -1;
 
 	ast_set_flag(&ast_options, AST_OPT_FLAG_FULLY_BOOTED);
+
+	ast_process_pending_reloads();
+
 	pthread_sigmask(SIG_UNBLOCK, &sigs, NULL);
 
 #ifdef __AST_DEBUG_MALLOC