summaryrefslogtreecommitdiff
path: root/main/loader.c
diff options
context:
space:
mode:
authorSean Bright <sean@malleable.com>2009-06-04 14:31:24 +0000
committerSean Bright <sean@malleable.com>2009-06-04 14:31:24 +0000
commitbefad1089389349e609acdad05794ca6d636ec89 (patch)
tree5e2d1ab43e93b994bcf7ebe75e826ef4db7ebd42 /main/loader.c
parent51a8d4a01d1f9234c6738a7d63b73ec371ef7cfe (diff)
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
Diffstat (limited to 'main/loader.c')
-rw-r--r--main/loader.c81
1 files changed, 81 insertions, 0 deletions
diff --git a/main/loader.c b/main/loader.c
index fefd29e80..8ce96be72 100644
--- a/main/loader.c
+++ b/main/loader.c
@@ -111,6 +111,15 @@ static AST_LIST_HEAD_STATIC(updaters, loadupdate);
AST_MUTEX_DEFINE_STATIC(reloadlock);
+struct reload_queue_item {
+ AST_LIST_ENTRY(reload_queue_item) entry;
+ char module[0];
+};
+
+static int do_full_reload = 0;
+
+static AST_LIST_HEAD_STATIC(reload_queue, reload_queue_item);
+
/* when dynamic modules are being loaded, ast_module_register() will
need to know what filename the module was loaded from while it
is being registered
@@ -544,12 +553,84 @@ char *ast_module_helper(const char *line, const char *word, int pos, int state,
return ret;
}
+void ast_process_pending_reloads(void)
+{
+ struct reload_queue_item *item;
+
+ if (!ast_fully_booted) {
+ return;
+ }
+
+ AST_LIST_LOCK(&reload_queue);
+
+ if (do_full_reload) {
+ do_full_reload = 0;
+ AST_LIST_UNLOCK(&reload_queue);
+ ast_log(LOG_NOTICE, "Executing deferred reload request.\n");
+ ast_module_reload(NULL);
+ return;
+ }
+
+ while ((item = AST_LIST_REMOVE_HEAD(&reload_queue, entry))) {
+ ast_log(LOG_NOTICE, "Executing deferred reload request for module '%s'.\n", item->module);
+ ast_module_reload(item->module);
+ ast_free(item);
+ }
+
+ AST_LIST_UNLOCK(&reload_queue);
+}
+
+static void queue_reload_request(const char *module)
+{
+ struct reload_queue_item *item;
+
+ AST_LIST_LOCK(&reload_queue);
+
+ if (do_full_reload) {
+ AST_LIST_UNLOCK(&reload_queue);
+ return;
+ }
+
+ if (ast_strlen_zero(module)) {
+ /* A full reload request (when module is NULL) wipes out any previous
+ reload requests and causes the queue to ignore future ones */
+ while ((item = AST_LIST_REMOVE_HEAD(&reload_queue, entry))) {
+ ast_free(item);
+ }
+ do_full_reload = 1;
+ } else {
+ /* No reason to add the same module twice */
+ AST_LIST_TRAVERSE(&reload_queue, item, entry) {
+ if (!strcasecmp(item->module, module)) {
+ AST_LIST_UNLOCK(&reload_queue);
+ return;
+ }
+ }
+ item = ast_calloc(1, sizeof(*item) + strlen(module) + 1);
+ if (!item) {
+ ast_log(LOG_ERROR, "Failed to allocate reload queue item.\n");
+ AST_LIST_UNLOCK(&reload_queue);
+ return;
+ }
+ strcpy(item->module, module);
+ AST_LIST_INSERT_TAIL(&reload_queue, item, entry);
+ }
+ AST_LIST_UNLOCK(&reload_queue);
+}
+
int ast_module_reload(const char *name)
{
struct ast_module *cur;
int res = 0; /* return value. 0 = not found, others, see below */
int i;
+ /* If we aren't fully booted, we just pretend we reloaded but we queue this
+ up to run once we are booted up. */
+ if (!ast_fully_booted) {
+ queue_reload_request(name);
+ return 0;
+ }
+
if (ast_mutex_trylock(&reloadlock)) {
ast_verbose("The previous reload command didn't finish yet\n");
return -1; /* reload already in progress */