diff options
author | seanbright <seanbright@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-06-04 14:14:57 +0000 |
---|---|---|
committer | seanbright <seanbright@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-06-04 14:14:57 +0000 |
commit | 1b57544d8db65c621f34d191e8604f1ad36c1a6b (patch) | |
tree | cd48f921499b6df88fb7ac31fe129c51e1267262 /include | |
parent | 0e21d4de4ae87afdd5ddf27a33de1cfb417f0d66 (diff) |
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.4@199022 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'include')
-rw-r--r-- | include/asterisk.h | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/include/asterisk.h b/include/asterisk.h index a827a23f0..41e98f022 100644 --- a/include/asterisk.h +++ b/include/asterisk.h @@ -126,6 +126,18 @@ struct ast_module; 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); + +/*! * \brief Register a function to be executed before Asterisk exits. * \param func The callback function to use. * |