From c6d42c0267db46fda69d17184c9313be22e09a2f Mon Sep 17 00:00:00 2001 From: seanbright Date: Thu, 4 Jun 2009 14:53:51 +0000 Subject: 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 #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: http://svn.digium.com/svn/asterisk/branches/1.6.1@199053 f38db490-d61c-443f-a65b-d21fe96a405b --- include/asterisk/_private.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'include') diff --git a/include/asterisk/_private.h b/include/asterisk/_private.h index 86db938c8..ee46e6ce0 100644 --- a/include/asterisk/_private.h +++ b/include/asterisk/_private.h @@ -56,4 +56,16 @@ int ast_timing_init(void); /*!< Provided by timing.c */ */ int ast_module_reload(const char *name); +/*! + * \brief Process reload requests received during startup. + * + * This function requests that the loader execute the pending reload requests + * that were queued during server startup. + * + * \note This function will do nothing if the server has not completely started + * up. Once called, the reload queue is emptied, and further invocations + * will have no affect. + */ +void ast_process_pending_reloads(void); + #endif /* _ASTERISK__PRIVATE_H */ -- cgit v1.2.3