aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorseanbright <seanbright@f38db490-d61c-443f-a65b-d21fe96a405b>2009-06-04 14:14:57 +0000
committerseanbright <seanbright@f38db490-d61c-443f-a65b-d21fe96a405b>2009-06-04 14:14:57 +0000
commit1b57544d8db65c621f34d191e8604f1ad36c1a6b (patch)
treecd48f921499b6df88fb7ac31fe129c51e1267262 /include
parent0e21d4de4ae87afdd5ddf27a33de1cfb417f0d66 (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.h12
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.
*