2006-08-21 02:11:39 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 1999 - 2006, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Mark Spencer <markster@digium.com>
|
|
|
|
* Kevin P. Fleming <kpfleming@digium.com>
|
|
|
|
* Luigi Rizzo <rizzo@icir.org>
|
|
|
|
*
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*! \file
|
|
|
|
*
|
|
|
|
* \brief Module Loader
|
2006-09-15 05:00:27 +00:00
|
|
|
* \author Mark Spencer <markster@digium.com>
|
2006-08-21 02:11:39 +00:00
|
|
|
* \author Kevin P. Fleming <kpfleming@digium.com>
|
|
|
|
* \author Luigi Rizzo <rizzo@icir.org>
|
|
|
|
* - See ModMngMnt
|
|
|
|
*/
|
|
|
|
|
2012-06-15 16:20:16 +00:00
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
2007-11-20 22:18:21 +00:00
|
|
|
#include "asterisk/_private.h"
|
2007-11-20 23:16:15 +00:00
|
|
|
#include "asterisk/paths.h" /* use ast_config_AST_MODULE_DIR */
|
2006-08-21 02:11:39 +00:00
|
|
|
#include <dirent.h>
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
#include "asterisk/dlinkedlists.h"
|
2006-08-21 02:11:39 +00:00
|
|
|
#include "asterisk/module.h"
|
|
|
|
#include "asterisk/config.h"
|
|
|
|
#include "asterisk/channel.h"
|
|
|
|
#include "asterisk/term.h"
|
2012-07-11 18:33:36 +00:00
|
|
|
#include "asterisk/acl.h"
|
2006-08-21 02:11:39 +00:00
|
|
|
#include "asterisk/manager.h"
|
|
|
|
#include "asterisk/cdr.h"
|
|
|
|
#include "asterisk/enum.h"
|
|
|
|
#include "asterisk/http.h"
|
|
|
|
#include "asterisk/lock.h"
|
2013-07-29 15:58:52 +00:00
|
|
|
#include "asterisk/features_config.h"
|
2008-03-05 16:23:44 +00:00
|
|
|
#include "asterisk/dsp.h"
|
2008-03-26 18:39:06 +00:00
|
|
|
#include "asterisk/udptl.h"
|
2009-06-09 16:22:04 +00:00
|
|
|
#include "asterisk/heap.h"
|
2010-01-27 18:29:49 +00:00
|
|
|
#include "asterisk/app.h"
|
2012-08-13 20:36:51 +00:00
|
|
|
#include "asterisk/test.h"
|
2013-08-16 12:20:59 +00:00
|
|
|
#include "asterisk/sounds_index.h"
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
#include <dlfcn.h>
|
|
|
|
|
|
|
|
#include "asterisk/md5.h"
|
|
|
|
#include "asterisk/utils.h"
|
|
|
|
|
2012-07-11 02:06:05 +00:00
|
|
|
/*** DOCUMENTATION
|
2013-05-24 20:44:07 +00:00
|
|
|
<managerEvent language="en_US" name="Reload">
|
|
|
|
<managerEventInstance class="EVENT_FLAG_SYSTEM">
|
|
|
|
<synopsis>Raised when a module has been reloaded in Asterisk.</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="Module">
|
|
|
|
<para>The name of the module that was reloaded, or
|
|
|
|
<literal>All</literal> if all modules were reloaded</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Status">
|
|
|
|
<para>The numeric status code denoting the success or failure
|
|
|
|
of the reload request.</para>
|
|
|
|
<enumlist>
|
|
|
|
<enum name="0"><para>Success</para></enum>
|
|
|
|
<enum name="1"><para>Request queued</para></enum>
|
|
|
|
<enum name="2"><para>Module not found</para></enum>
|
|
|
|
<enum name="3"><para>Error</para></enum>
|
|
|
|
<enum name="4"><para>Reload already in progress</para></enum>
|
|
|
|
<enum name="5"><para>Module uninitialized</para></enum>
|
|
|
|
<enum name="6"><para>Reload not supported</para></enum>
|
|
|
|
</enumlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
</managerEventInstance>
|
|
|
|
</managerEvent>
|
2012-07-11 02:06:05 +00:00
|
|
|
***/
|
|
|
|
|
2007-10-22 14:56:05 +00:00
|
|
|
#ifndef RTLD_NOW
|
2006-08-21 02:11:39 +00:00
|
|
|
#define RTLD_NOW 0
|
|
|
|
#endif
|
|
|
|
|
2007-11-17 09:51:45 +00:00
|
|
|
#ifndef RTLD_LOCAL
|
|
|
|
#define RTLD_LOCAL 0
|
|
|
|
#endif
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
struct ast_module_user {
|
|
|
|
struct ast_channel *chan;
|
|
|
|
AST_LIST_ENTRY(ast_module_user) entry;
|
|
|
|
};
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_HEAD(module_user_list, ast_module_user);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static const unsigned char expected_key[] =
|
2006-08-21 02:11:39 +00:00
|
|
|
{ 0x87, 0x76, 0x79, 0x35, 0x23, 0xea, 0x3a, 0xd3,
|
|
|
|
0x25, 0x2a, 0xbb, 0x35, 0x87, 0xe4, 0x22, 0x24 };
|
|
|
|
|
2007-11-20 19:28:10 +00:00
|
|
|
static char buildopt_sum[33] = AST_BUILDOPT_SUM;
|
2007-11-16 16:56:59 +00:00
|
|
|
|
2015-04-09 23:08:10 +00:00
|
|
|
/*!
|
|
|
|
* \brief Internal flag to indicate all modules have been initially loaded.
|
|
|
|
*/
|
|
|
|
static int modules_loaded;
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
struct ast_module {
|
|
|
|
const struct ast_module_info *info;
|
2015-04-17 07:16:59 +00:00
|
|
|
/* Used to get module references into refs log */
|
2015-02-11 17:03:04 +00:00
|
|
|
void *ref_debug;
|
2006-08-21 02:11:39 +00:00
|
|
|
void *lib; /* the shared lib, or NULL if embedded */
|
|
|
|
int usecount; /* the number of 'users' currently in this module */
|
|
|
|
struct module_user_list users; /* the list of users in the module */
|
2007-05-03 16:43:49 +00:00
|
|
|
struct {
|
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
|
|
|
unsigned int running:1;
|
|
|
|
unsigned int declined:1;
|
2015-02-11 17:03:04 +00:00
|
|
|
unsigned int keepuntilshutdown:1;
|
2007-05-03 16:43:49 +00:00
|
|
|
} flags;
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_LIST_ENTRY(ast_module) list_entry;
|
|
|
|
AST_DLLIST_ENTRY(ast_module) entry;
|
2006-08-21 02:11:39 +00:00
|
|
|
char resource[0];
|
|
|
|
};
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
static AST_DLLIST_HEAD_STATIC(module_list, ast_module);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2011-10-10 14:16:27 +00:00
|
|
|
const char *ast_module_name(const struct ast_module *mod)
|
|
|
|
{
|
|
|
|
if (!mod || !mod->info) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mod->info->name;
|
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
struct loadupdate {
|
|
|
|
int (*updater)(void);
|
|
|
|
AST_LIST_ENTRY(loadupdate) entry;
|
|
|
|
};
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
static AST_DLLIST_HEAD_STATIC(updaters, loadupdate);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
AST_MUTEX_DEFINE_STATIC(reloadlock);
|
|
|
|
|
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
2009-06-04 14:31:24 +00:00
|
|
|
struct reload_queue_item {
|
|
|
|
AST_LIST_ENTRY(reload_queue_item) entry;
|
|
|
|
char module[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
static int do_full_reload = 0;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
static AST_DLLIST_HEAD_STATIC(reload_queue, reload_queue_item);
|
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
2009-06-04 14:31:24 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
/* 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
|
|
|
|
*/
|
2009-06-15 17:34:30 +00:00
|
|
|
static struct ast_module *resource_being_loaded;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
/* XXX: should we check for duplicate resource names here? */
|
|
|
|
|
|
|
|
void ast_module_register(const struct ast_module_info *info)
|
|
|
|
{
|
2017-03-24 12:43:05 +00:00
|
|
|
struct ast_module *mod = resource_being_loaded;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2014-05-28 22:54:12 +00:00
|
|
|
ast_debug(5, "Registering module %s\n", info->name);
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
mod->info = info;
|
2015-04-17 07:16:59 +00:00
|
|
|
if (ast_opt_ref_debug) {
|
|
|
|
mod->ref_debug = ao2_t_alloc(0, NULL, info->name);
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_HEAD_INIT(&mod->users);
|
|
|
|
|
|
|
|
/* during startup, before the loader has been initialized,
|
|
|
|
there are no threads, so there is no need to take the lock
|
|
|
|
on this list to manipulate it. it is also possible that it
|
|
|
|
might be unsafe to use the list lock at that point... so
|
|
|
|
let's avoid it altogether
|
|
|
|
*/
|
2017-03-24 12:43:05 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
/* it is paramount that the new entry be placed at the tail of
|
|
|
|
the list, otherwise the code that uses dlopen() to load
|
|
|
|
dynamic modules won't be able to find out if the module it
|
|
|
|
just opened was registered or failed to load
|
|
|
|
*/
|
|
|
|
AST_DLLIST_INSERT_TAIL(&module_list, mod, entry);
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
/* give the module a copy of its own handle, for later use in registrations and the like */
|
|
|
|
*((struct ast_module **) &(info->self)) = mod;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_module_unregister(const struct ast_module_info *info)
|
|
|
|
{
|
|
|
|
struct ast_module *mod = NULL;
|
|
|
|
|
|
|
|
/* it is assumed that the users list in the module structure
|
|
|
|
will already be empty, or we cannot have gotten to this
|
|
|
|
point
|
|
|
|
*/
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
AST_DLLIST_TRAVERSE_BACKWARDS_SAFE_BEGIN(&module_list, mod, entry) {
|
2006-08-21 02:11:39 +00:00
|
|
|
if (mod->info == info) {
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_REMOVE_CURRENT(entry);
|
2006-08-21 02:11:39 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_TRAVERSE_BACKWARDS_SAFE_END;
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
if (mod) {
|
2014-05-28 22:54:12 +00:00
|
|
|
ast_debug(5, "Unregistering module %s\n", info->name);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_HEAD_DESTROY(&mod->users);
|
2015-02-11 17:03:04 +00:00
|
|
|
ao2_cleanup(mod->ref_debug);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(mod);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-05 21:42:49 +00:00
|
|
|
struct ast_module_user *__ast_module_user_add(struct ast_module *mod, struct ast_channel *chan)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2012-11-05 21:42:49 +00:00
|
|
|
struct ast_module_user *u;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2012-11-05 21:42:49 +00:00
|
|
|
u = ast_calloc(1, sizeof(*u));
|
|
|
|
if (!u) {
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
2012-11-05 21:42:49 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
u->chan = chan;
|
|
|
|
|
|
|
|
AST_LIST_LOCK(&mod->users);
|
|
|
|
AST_LIST_INSERT_HEAD(&mod->users, u, entry);
|
|
|
|
AST_LIST_UNLOCK(&mod->users);
|
|
|
|
|
2015-04-17 07:16:59 +00:00
|
|
|
if (mod->ref_debug) {
|
|
|
|
ao2_ref(mod->ref_debug, +1);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_atomic_fetchadd_int(&mod->usecount, +1);
|
|
|
|
|
|
|
|
ast_update_use_count();
|
|
|
|
|
|
|
|
return u;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __ast_module_user_remove(struct ast_module *mod, struct ast_module_user *u)
|
|
|
|
{
|
2012-11-05 21:42:49 +00:00
|
|
|
if (!u) {
|
|
|
|
return;
|
|
|
|
}
|
2012-12-17 23:10:42 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_LOCK(&mod->users);
|
2012-12-17 23:10:42 +00:00
|
|
|
u = AST_LIST_REMOVE(&mod->users, u, entry);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_UNLOCK(&mod->users);
|
2012-12-17 23:10:42 +00:00
|
|
|
if (!u) {
|
|
|
|
/*
|
|
|
|
* Was not in the list. Either a bad pointer or
|
|
|
|
* __ast_module_user_hangup_all() has been called.
|
|
|
|
*/
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-04-17 07:16:59 +00:00
|
|
|
if (mod->ref_debug) {
|
|
|
|
ao2_ref(mod->ref_debug, -1);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_atomic_fetchadd_int(&mod->usecount, -1);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(u);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
ast_update_use_count();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __ast_module_user_hangup_all(struct ast_module *mod)
|
|
|
|
{
|
|
|
|
struct ast_module_user *u;
|
|
|
|
|
|
|
|
AST_LIST_LOCK(&mod->users);
|
|
|
|
while ((u = AST_LIST_REMOVE_HEAD(&mod->users, entry))) {
|
2012-02-22 21:22:43 +00:00
|
|
|
if (u->chan) {
|
|
|
|
ast_softhangup(u->chan, AST_SOFTHANGUP_APPUNLOAD);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2015-04-17 07:16:59 +00:00
|
|
|
if (mod->ref_debug) {
|
|
|
|
ao2_ref(mod->ref_debug, -1);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_atomic_fetchadd_int(&mod->usecount, -1);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(u);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
AST_LIST_UNLOCK(&mod->users);
|
|
|
|
|
2008-03-04 23:04:29 +00:00
|
|
|
ast_update_use_count();
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*! \note
|
|
|
|
* In addition to modules, the reload command handles some extra keywords
|
|
|
|
* which are listed here together with the corresponding handlers.
|
|
|
|
* This table is also used by the command completion code.
|
|
|
|
*/
|
|
|
|
static struct reload_classes {
|
|
|
|
const char *name;
|
|
|
|
int (*reload_fn)(void);
|
|
|
|
} reload_classes[] = { /* list in alpha order, longest match first for cli completion */
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
{ "acl", ast_named_acl_reload },
|
|
|
|
{ "cdr", ast_cdr_engine_reload },
|
|
|
|
{ "cel", ast_cel_engine_reload },
|
|
|
|
{ "dnsmgr", dnsmgr_reload },
|
|
|
|
{ "dsp", ast_dsp_reload},
|
|
|
|
{ "extconfig", read_config_maps },
|
|
|
|
{ "enum", ast_enum_reload },
|
|
|
|
{ "features", ast_features_config_reload },
|
|
|
|
{ "http", ast_http_reload },
|
2009-02-17 20:41:24 +00:00
|
|
|
{ "indications", ast_indications_reload },
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
{ "logger", logger_reload },
|
|
|
|
{ "manager", reload_manager },
|
|
|
|
{ "plc", ast_plc_reload },
|
|
|
|
{ "sounds", ast_sounds_reindex },
|
|
|
|
{ "udptl", ast_udptl_reload },
|
|
|
|
{ NULL, NULL }
|
2006-08-21 02:11:39 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static int printdigest(const unsigned char *d)
|
|
|
|
{
|
|
|
|
int x, pos;
|
|
|
|
char buf[256]; /* large enough so we don't have to worry */
|
|
|
|
|
|
|
|
for (pos = 0, x = 0; x < 16; x++)
|
2014-12-17 10:23:32 +00:00
|
|
|
pos += sprintf(buf + pos, " %02hhx", *d++);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2007-06-24 18:51:41 +00:00
|
|
|
ast_debug(1, "Unexpected signature:%s\n", buf);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int key_matches(const unsigned char *key1, const unsigned char *key2)
|
|
|
|
{
|
|
|
|
int x;
|
|
|
|
|
|
|
|
for (x = 0; x < 16; x++) {
|
|
|
|
if (key1[x] != key2[x])
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int verify_key(const unsigned char *key)
|
|
|
|
{
|
|
|
|
struct MD5Context c;
|
|
|
|
unsigned char digest[16];
|
|
|
|
|
|
|
|
MD5Init(&c);
|
|
|
|
MD5Update(&c, key, strlen((char *)key));
|
|
|
|
MD5Final(digest, &c);
|
|
|
|
|
|
|
|
if (key_matches(expected_key, digest))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
printdigest(digest);
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int resource_name_match(const char *name1_in, const char *name2_in)
|
|
|
|
{
|
|
|
|
char *name1 = (char *) name1_in;
|
|
|
|
char *name2 = (char *) name2_in;
|
|
|
|
|
|
|
|
/* trim off any .so extensions */
|
|
|
|
if (!strcasecmp(name1 + strlen(name1) - 3, ".so")) {
|
|
|
|
name1 = ast_strdupa(name1);
|
|
|
|
name1[strlen(name1) - 3] = '\0';
|
|
|
|
}
|
|
|
|
if (!strcasecmp(name2 + strlen(name2) - 3, ".so")) {
|
|
|
|
name2 = ast_strdupa(name2);
|
|
|
|
name2[strlen(name2) - 3] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
return strcasecmp(name1, name2);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_module *find_resource(const char *resource, int do_lock)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
if (do_lock) {
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
2006-08-21 02:11:39 +00:00
|
|
|
if (!resource_name_match(resource, cur->resource))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
if (do_lock) {
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return cur;
|
|
|
|
}
|
|
|
|
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
/*!
|
|
|
|
* \brief dlclose(), with failure logging.
|
|
|
|
*/
|
|
|
|
static void logged_dlclose(const char *name, void *lib)
|
|
|
|
{
|
core/loader: Don't call dlclose in a while loop
For awhile now, we've noticed continuous integration builds hanging on CentOS 6
64-bit build agents. After resolving a number of problems with symbols, strange
locks, and other shenanigans, the problem has persisted. In all cases, gdb
shows the Asterisk process stuck in loader.c on one of the infinite while loops
that calls dlclose repeatedly until success.
The documentation of dlclose states that it returns 0 on success; any other
value on error. It does not state that repeatedly calling it will eventually
clear those errors. Most likely, the repeated calls to dlclose was to force a
close by exhausting the references on the library; however, that will never
succeed if:
(a) There is some fundamental error at work in the loaded library that
precludes unloading it
(b) Some other loaded module is referencing a symbol in the currently loaded
module
This results in Asterisk sitting forever.
Since we have matching pairs of dlopen/dlclose, this patch opts to only call
dlclose once, and log out as an ERROR if dlclose fails to return success. If
nothing else, this might help to determine why on the CentOS 6 64-bit build agent
things are not closing successfully.
Review: https://reviewboard.asterisk.org/r/2970
........
Merged revisions 402287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402288 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402289 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-31 16:06:14 +00:00
|
|
|
char *error;
|
|
|
|
|
|
|
|
if (!lib) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear any existing error */
|
|
|
|
dlerror();
|
|
|
|
if (dlclose(lib)) {
|
|
|
|
error = dlerror();
|
|
|
|
ast_log(AST_LOG_ERROR, "Failure in dlclose for module '%s': %s\n",
|
|
|
|
S_OR(name, "unknown"), S_OR(error, "Unknown error"));
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(HAVE_RTLD_NOLOAD)
|
|
|
|
/*!
|
|
|
|
* \brief Check to see if the given resource is loaded.
|
|
|
|
*
|
|
|
|
* \param resource_name Name of the resource, including .so suffix.
|
|
|
|
* \return False (0) if module is not loaded.
|
|
|
|
* \return True (non-zero) if module is loaded.
|
|
|
|
*/
|
|
|
|
static int is_module_loaded(const char *resource_name)
|
|
|
|
{
|
|
|
|
char fn[PATH_MAX] = "";
|
|
|
|
void *lib;
|
|
|
|
|
|
|
|
snprintf(fn, sizeof(fn), "%s/%s", ast_config_AST_MODULE_DIR,
|
|
|
|
resource_name);
|
|
|
|
|
|
|
|
lib = dlopen(fn, RTLD_LAZY | RTLD_NOLOAD);
|
|
|
|
|
|
|
|
if (lib) {
|
|
|
|
logged_dlclose(resource_name, lib);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
static void unload_dynamic_module(struct ast_module *mod)
|
|
|
|
{
|
2015-03-22 23:11:32 +00:00
|
|
|
#if defined(HAVE_RTLD_NOLOAD)
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
char *name = ast_strdupa(ast_module_name(mod));
|
2015-03-22 23:11:32 +00:00
|
|
|
#endif
|
2006-08-26 19:45:16 +00:00
|
|
|
void *lib = mod->lib;
|
|
|
|
|
|
|
|
/* WARNING: the structure pointed to by mod is going to
|
|
|
|
disappear when this operation succeeds, so we can't
|
|
|
|
dereference it */
|
core/loader: Don't call dlclose in a while loop
For awhile now, we've noticed continuous integration builds hanging on CentOS 6
64-bit build agents. After resolving a number of problems with symbols, strange
locks, and other shenanigans, the problem has persisted. In all cases, gdb
shows the Asterisk process stuck in loader.c on one of the infinite while loops
that calls dlclose repeatedly until success.
The documentation of dlclose states that it returns 0 on success; any other
value on error. It does not state that repeatedly calling it will eventually
clear those errors. Most likely, the repeated calls to dlclose was to force a
close by exhausting the references on the library; however, that will never
succeed if:
(a) There is some fundamental error at work in the loaded library that
precludes unloading it
(b) Some other loaded module is referencing a symbol in the currently loaded
module
This results in Asterisk sitting forever.
Since we have matching pairs of dlopen/dlclose, this patch opts to only call
dlclose once, and log out as an ERROR if dlclose fails to return success. If
nothing else, this might help to determine why on the CentOS 6 64-bit build agent
things are not closing successfully.
Review: https://reviewboard.asterisk.org/r/2970
........
Merged revisions 402287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402288 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402289 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-31 16:06:14 +00:00
|
|
|
logged_dlclose(ast_module_name(mod), lib);
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
|
|
|
|
/* There are several situations where the module might still be resident
|
|
|
|
* in memory.
|
|
|
|
*
|
|
|
|
* If somehow there was another dlopen() on the same module (unlikely,
|
|
|
|
* since that all is supposed to happen in loader.c).
|
|
|
|
*
|
|
|
|
* Or the lazy resolution of a global symbol (very likely, since that is
|
|
|
|
* how we load all of our modules that export global symbols).
|
|
|
|
*
|
|
|
|
* Avoid the temptation of repeating the dlclose(). The other code that
|
|
|
|
* dlopened the module still has its module reference, and should close
|
|
|
|
* it itself. In other situations, dlclose() will happily return success
|
|
|
|
* for as many times as you wish to call it.
|
|
|
|
*/
|
|
|
|
#if defined(HAVE_RTLD_NOLOAD)
|
|
|
|
if (is_module_loaded(name)) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' could not be completely unloaded\n", name);
|
|
|
|
}
|
|
|
|
#endif
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2016-01-23 21:50:57 +00:00
|
|
|
static enum ast_module_load_result load_resource(const char *resource_name, unsigned int global_symbols_only, unsigned int suppress_logging, struct ast_heap *resource_heap, int required);
|
2012-09-27 16:53:19 +00:00
|
|
|
|
2016-01-23 21:50:57 +00:00
|
|
|
#define MODULE_LOCAL_ONLY (void *)-1
|
|
|
|
|
|
|
|
static struct ast_module *load_dynamic_module(const char *resource_in, unsigned int global_symbols_only, unsigned int suppress_logging, struct ast_heap *resource_heap)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2008-01-02 09:16:17 +00:00
|
|
|
char fn[PATH_MAX] = "";
|
2007-03-07 20:05:05 +00:00
|
|
|
void *lib = NULL;
|
2006-08-21 02:11:39 +00:00
|
|
|
struct ast_module *mod;
|
2006-08-21 14:42:03 +00:00
|
|
|
unsigned int wants_global;
|
2008-01-02 09:16:17 +00:00
|
|
|
int space; /* room needed for the descriptor */
|
|
|
|
int missing_so = 0;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2008-01-02 09:16:17 +00:00
|
|
|
space = sizeof(*resource_being_loaded) + strlen(resource_in) + 1;
|
|
|
|
if (strcasecmp(resource_in + strlen(resource_in) - 3, ".so")) {
|
|
|
|
missing_so = 1;
|
|
|
|
space += 3; /* room for the extra ".so" */
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2008-01-02 09:16:17 +00:00
|
|
|
snprintf(fn, sizeof(fn), "%s/%s%s", ast_config_AST_MODULE_DIR, resource_in, missing_so ? ".so" : "");
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2006-08-21 14:42:03 +00:00
|
|
|
/* make a first load of the module in 'quiet' mode... don't try to resolve
|
|
|
|
any symbols, and don't export any symbols. this will allow us to peek into
|
|
|
|
the module's info block (if available) to see what flags it has set */
|
|
|
|
|
2008-01-02 09:16:17 +00:00
|
|
|
resource_being_loaded = ast_calloc(1, space);
|
|
|
|
if (!resource_being_loaded)
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
2008-01-02 09:16:17 +00:00
|
|
|
strcpy(resource_being_loaded->resource, resource_in);
|
|
|
|
if (missing_so)
|
|
|
|
strcat(resource_being_loaded->resource, ".so");
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2016-01-23 21:50:57 +00:00
|
|
|
if (!(lib = dlopen(fn, RTLD_LAZY | RTLD_GLOBAL))) {
|
|
|
|
if (!suppress_logging) {
|
|
|
|
ast_log(LOG_WARNING, "Error loading module '%s': %s\n", resource_in, dlerror());
|
|
|
|
}
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(resource_being_loaded);
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* the dlopen() succeeded, let's find out if the module
|
|
|
|
registered itself */
|
|
|
|
/* note that this will only work properly as long as
|
|
|
|
ast_module_register() (which is called by the module's
|
|
|
|
constructor) places the new module at the tail of the
|
|
|
|
module_list
|
|
|
|
*/
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
if (resource_being_loaded != (mod = AST_DLLIST_LAST(&module_list))) {
|
2006-10-04 00:26:21 +00:00
|
|
|
ast_log(LOG_WARNING, "Module '%s' did not register itself during load\n", resource_in);
|
2006-08-21 02:11:39 +00:00
|
|
|
/* no, it did not, so close it and return */
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
logged_dlclose(resource_in, lib);
|
2006-08-21 14:42:03 +00:00
|
|
|
/* note that the module's destructor will call ast_module_unregister(),
|
|
|
|
which will free the structure we allocated in resource_being_loaded */
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2006-08-21 14:42:03 +00:00
|
|
|
wants_global = ast_test_flag(mod->info, AST_MODFLAG_GLOBAL_SYMBOLS);
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
/* if we are being asked only to load modules that provide global symbols,
|
|
|
|
and this one does not, then close it and return */
|
2006-08-23 19:28:13 +00:00
|
|
|
if (global_symbols_only && !wants_global) {
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
logged_dlclose(resource_in, lib);
|
2016-01-23 21:50:57 +00:00
|
|
|
return MODULE_LOCAL_ONLY;
|
2006-08-23 19:28:13 +00:00
|
|
|
}
|
|
|
|
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
logged_dlclose(resource_in, lib);
|
2006-08-23 19:28:13 +00:00
|
|
|
resource_being_loaded = NULL;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2006-08-21 14:42:03 +00:00
|
|
|
/* start the load process again */
|
2008-01-02 09:16:17 +00:00
|
|
|
resource_being_loaded = ast_calloc(1, space);
|
|
|
|
if (!resource_being_loaded)
|
2006-08-21 14:42:03 +00:00
|
|
|
return NULL;
|
2008-01-02 09:16:17 +00:00
|
|
|
strcpy(resource_being_loaded->resource, resource_in);
|
|
|
|
if (missing_so)
|
|
|
|
strcat(resource_being_loaded->resource, ".so");
|
2006-08-21 14:42:03 +00:00
|
|
|
|
|
|
|
if (!(lib = dlopen(fn, wants_global ? RTLD_LAZY | RTLD_GLOBAL : RTLD_NOW | RTLD_LOCAL))) {
|
2006-10-04 00:26:21 +00:00
|
|
|
ast_log(LOG_WARNING, "Error loading module '%s': %s\n", resource_in, dlerror());
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(resource_being_loaded);
|
2006-08-21 14:42:03 +00:00
|
|
|
return NULL;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 14:42:03 +00:00
|
|
|
/* since the module was successfully opened, and it registered itself
|
|
|
|
the previous time we did that, we're going to assume it worked this
|
|
|
|
time too :) */
|
2006-08-23 19:28:13 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LAST(&module_list)->lib = lib;
|
2006-08-21 14:42:03 +00:00
|
|
|
resource_being_loaded = NULL;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
return AST_DLLIST_LAST(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
optional_api: Fix linking problems between modules that export global symbols
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-30 13:40:27 +00:00
|
|
|
|
2016-10-28 02:49:43 +00:00
|
|
|
int modules_shutdown(void)
|
2007-06-05 15:54:36 +00:00
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
2009-11-09 07:37:52 +00:00
|
|
|
int somethingchanged = 1, final = 0;
|
2007-06-05 15:54:36 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
2007-06-05 15:54:36 +00:00
|
|
|
|
2009-11-09 07:37:52 +00:00
|
|
|
/*!\note Some resources, like timers, are started up dynamically, and thus
|
|
|
|
* may be still in use, even if all channels are dead. We must therefore
|
|
|
|
* check the usecount before asking modules to unload. */
|
|
|
|
do {
|
|
|
|
if (!somethingchanged) {
|
|
|
|
/*!\note If we go through the entire list without changing
|
|
|
|
* anything, ignore the usecounts and unload, then exit. */
|
|
|
|
final = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reset flag before traversing the list */
|
|
|
|
somethingchanged = 0;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_TRAVERSE_BACKWARDS_SAFE_BEGIN(&module_list, mod, entry) {
|
2009-11-09 07:37:52 +00:00
|
|
|
if (!final && mod->usecount) {
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
ast_debug(1, "Passing on %s: its use count is %d\n",
|
|
|
|
mod->resource, mod->usecount);
|
2009-11-09 07:37:52 +00:00
|
|
|
continue;
|
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_REMOVE_CURRENT(entry);
|
2010-07-09 17:50:45 +00:00
|
|
|
if (mod->flags.running && !mod->flags.declined && mod->info->unload) {
|
2013-05-10 17:12:57 +00:00
|
|
|
ast_verb(1, "Unloading %s\n", mod->resource);
|
2009-11-09 07:37:52 +00:00
|
|
|
mod->info->unload();
|
|
|
|
}
|
|
|
|
AST_LIST_HEAD_DESTROY(&mod->users);
|
2015-02-11 17:03:04 +00:00
|
|
|
ao2_cleanup(mod->ref_debug);
|
2014-09-26 14:41:38 +00:00
|
|
|
ast_free(mod);
|
2009-11-09 07:37:52 +00:00
|
|
|
somethingchanged = 1;
|
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_TRAVERSE_BACKWARDS_SAFE_END;
|
2015-02-11 17:03:04 +00:00
|
|
|
if (!somethingchanged) {
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, mod, entry) {
|
|
|
|
if (mod->flags.keepuntilshutdown) {
|
|
|
|
ast_module_unref(mod);
|
|
|
|
mod->flags.keepuntilshutdown = 0;
|
|
|
|
somethingchanged = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-11-09 07:37:52 +00:00
|
|
|
} while (somethingchanged && !final);
|
|
|
|
|
2016-10-28 02:49:43 +00:00
|
|
|
final = AST_DLLIST_EMPTY(&module_list);
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2016-10-28 02:49:43 +00:00
|
|
|
|
|
|
|
return !final;
|
2007-06-05 15:54:36 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
int ast_unload_resource(const char *resource_name, enum ast_module_unload_mode force)
|
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
|
|
|
int res = -1;
|
|
|
|
int error = 0;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2006-08-22 23:06:13 +00:00
|
|
|
if (!(mod = find_resource(resource_name, 0))) {
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2008-02-19 21:54:09 +00:00
|
|
|
ast_log(LOG_WARNING, "Unload failed, '%s' could not be found\n", resource_name);
|
2010-05-12 19:59:16 +00:00
|
|
|
return -1;
|
2006-08-22 23:06:13 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2010-07-09 18:24:03 +00:00
|
|
|
if (!mod->flags.running || mod->flags.declined) {
|
|
|
|
ast_log(LOG_WARNING, "Unload failed, '%s' is not loaded.\n", resource_name);
|
2006-08-21 02:11:39 +00:00
|
|
|
error = 1;
|
2010-07-09 18:24:03 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
if (!error && (mod->usecount > 0)) {
|
2006-09-15 05:00:27 +00:00
|
|
|
if (force)
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_log(LOG_WARNING, "Warning: Forcing removal of module '%s' with use count %d\n",
|
|
|
|
resource_name, mod->usecount);
|
|
|
|
else {
|
|
|
|
ast_log(LOG_WARNING, "Soft unload failed, '%s' has use count %d\n", resource_name,
|
|
|
|
mod->usecount);
|
|
|
|
error = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!error) {
|
2012-12-17 23:10:42 +00:00
|
|
|
/* Request any channels attached to the module to hangup. */
|
2006-08-21 02:11:39 +00:00
|
|
|
__ast_module_user_hangup_all(mod);
|
|
|
|
|
2013-05-10 17:12:57 +00:00
|
|
|
ast_verb(1, "Unloading %s\n", mod->resource);
|
2012-12-17 23:10:42 +00:00
|
|
|
res = mod->info->unload();
|
2006-08-21 02:11:39 +00:00
|
|
|
if (res) {
|
|
|
|
ast_log(LOG_WARNING, "Firm unload failed for %s\n", resource_name);
|
2012-12-17 23:10:42 +00:00
|
|
|
if (force <= AST_FORCE_FIRM) {
|
2006-08-21 02:11:39 +00:00
|
|
|
error = 1;
|
2012-12-17 23:10:42 +00:00
|
|
|
} else {
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_log(LOG_WARNING, "** Dangerous **: Unloading resource anyway, at user request\n");
|
2012-12-17 23:10:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!error) {
|
|
|
|
/*
|
|
|
|
* Request hangup on any channels that managed to get attached
|
|
|
|
* while we called the module unload function.
|
|
|
|
*/
|
|
|
|
__ast_module_user_hangup_all(mod);
|
|
|
|
sched_yield();
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!error)
|
2007-05-03 16:43:49 +00:00
|
|
|
mod->flags.running = mod->flags.declined = 0;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2012-08-13 20:36:51 +00:00
|
|
|
if (!error) {
|
2006-08-21 02:11:39 +00:00
|
|
|
unload_dynamic_module(mod);
|
2012-08-13 20:36:51 +00:00
|
|
|
ast_test_suite_event_notify("MODULE_UNLOAD", "Message: %s", resource_name);
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_update_use_count();
|
2017-03-24 12:43:05 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *ast_module_helper(const char *line, const char *word, int pos, int state, int rpos, int needsreload)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
int i, which=0, l = strlen(word);
|
|
|
|
char *ret = NULL;
|
|
|
|
|
|
|
|
if (pos != rpos)
|
|
|
|
return NULL;
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
2006-08-21 02:11:39 +00:00
|
|
|
if (!strncasecmp(word, cur->resource, l) &&
|
|
|
|
(cur->info->reload || !needsreload) &&
|
|
|
|
++which > state) {
|
2007-06-14 23:01:01 +00:00
|
|
|
ret = ast_strdup(cur->resource);
|
2006-08-21 02:11:39 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
if (!ret) {
|
|
|
|
for (i=0; !ret && reload_classes[i].name; i++) {
|
|
|
|
if (!strncasecmp(word, reload_classes[i].name, l) && ++which > state)
|
2007-06-14 23:01:01 +00:00
|
|
|
ret = ast_strdup(reload_classes[i].name);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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
2009-06-04 14:31:24 +00:00
|
|
|
void ast_process_pending_reloads(void)
|
|
|
|
{
|
|
|
|
struct reload_queue_item *item;
|
|
|
|
|
2015-04-09 23:08:10 +00:00
|
|
|
modules_loaded = 1;
|
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
2009-06-04 14:31:24 +00:00
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2013-05-24 20:44:07 +00:00
|
|
|
/*!
|
|
|
|
* \since 12
|
|
|
|
* \internal
|
|
|
|
* \brief Publish a \ref stasis message regarding the reload result
|
|
|
|
*/
|
|
|
|
static void publish_reload_message(const char *name, enum ast_module_reload_result result)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct stasis_message *, message, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(struct ast_json_payload *, payload, NULL, ao2_cleanup);
|
|
|
|
RAII_VAR(struct ast_json *, json_object, NULL, ast_json_unref);
|
|
|
|
RAII_VAR(struct ast_json *, event_object, NULL, ast_json_unref);
|
|
|
|
char res_buffer[8];
|
|
|
|
|
2014-08-06 12:55:28 +00:00
|
|
|
if (!ast_manager_get_generic_type()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-05-09 22:49:26 +00:00
|
|
|
snprintf(res_buffer, sizeof(res_buffer), "%u", result);
|
2013-05-24 20:44:07 +00:00
|
|
|
event_object = ast_json_pack("{s: s, s: s}",
|
|
|
|
"Module", S_OR(name, "All"),
|
|
|
|
"Status", res_buffer);
|
2015-12-14 18:04:15 +00:00
|
|
|
json_object = ast_json_pack("{s: s, s: i, s: o}",
|
2013-05-24 20:44:07 +00:00
|
|
|
"type", "Reload",
|
|
|
|
"class_type", EVENT_FLAG_SYSTEM,
|
2015-12-14 18:04:15 +00:00
|
|
|
"event", ast_json_ref(event_object));
|
2013-05-24 20:44:07 +00:00
|
|
|
|
|
|
|
if (!json_object) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
payload = ast_json_payload_create(json_object);
|
|
|
|
if (!payload) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
message = stasis_message_create(ast_manager_get_generic_type(), payload);
|
|
|
|
if (!message) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
stasis_publish(ast_manager_get_topic(), message);
|
|
|
|
}
|
|
|
|
|
|
|
|
enum ast_module_reload_result ast_module_reload(const char *name)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
2013-05-24 20:44:07 +00:00
|
|
|
enum ast_module_reload_result res = AST_MODULE_RELOAD_NOT_FOUND;
|
2006-08-21 02:11:39 +00:00
|
|
|
int i;
|
|
|
|
|
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
2009-06-04 14:31:24 +00:00
|
|
|
/* If we aren't fully booted, we just pretend we reloaded but we queue this
|
|
|
|
up to run once we are booted up. */
|
2015-04-09 23:08:10 +00:00
|
|
|
if (!modules_loaded) {
|
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
2009-06-04 14:31:24 +00:00
|
|
|
queue_reload_request(name);
|
2013-05-24 20:44:07 +00:00
|
|
|
res = AST_MODULE_RELOAD_QUEUED;
|
|
|
|
goto module_reload_exit;
|
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
2009-06-04 14:31:24 +00:00
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
if (ast_mutex_trylock(&reloadlock)) {
|
2014-05-28 22:54:12 +00:00
|
|
|
ast_verb(3, "The previous reload command didn't finish yet\n");
|
2013-05-24 20:44:07 +00:00
|
|
|
res = AST_MODULE_RELOAD_IN_PROGRESS;
|
|
|
|
goto module_reload_exit;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
2016-06-27 19:26:54 +00:00
|
|
|
ast_sd_notify("RELOAD=1");
|
2007-07-18 19:47:20 +00:00
|
|
|
ast_lastreloadtime = ast_tvnow();
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2010-01-27 18:29:49 +00:00
|
|
|
if (ast_opt_lock_confdir) {
|
|
|
|
int try;
|
|
|
|
int res;
|
|
|
|
for (try = 1, res = AST_LOCK_TIMEOUT; try < 6 && (res == AST_LOCK_TIMEOUT); try++) {
|
|
|
|
res = ast_lock_path(ast_config_AST_CONFIG_DIR);
|
|
|
|
if (res == AST_LOCK_TIMEOUT) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to grab lock on %s, try %d\n", ast_config_AST_CONFIG_DIR, try);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (res != AST_LOCK_SUCCESS) {
|
2014-05-28 22:54:12 +00:00
|
|
|
ast_log(AST_LOG_WARNING, "Cannot grab lock on %s\n", ast_config_AST_CONFIG_DIR);
|
2013-05-24 20:44:07 +00:00
|
|
|
res = AST_MODULE_RELOAD_ERROR;
|
2016-06-27 19:26:54 +00:00
|
|
|
goto module_reload_done;
|
2010-01-27 18:29:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
/* Call "predefined" reload here first */
|
|
|
|
for (i = 0; reload_classes[i].name; i++) {
|
|
|
|
if (!name || !strcasecmp(name, reload_classes[i].name)) {
|
2013-05-24 20:44:07 +00:00
|
|
|
if (reload_classes[i].reload_fn() == AST_MODULE_LOAD_SUCCESS) {
|
|
|
|
res = AST_MODULE_RELOAD_SUCCESS;
|
2012-08-17 16:01:32 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-24 20:44:07 +00:00
|
|
|
if (name && res == AST_MODULE_RELOAD_SUCCESS) {
|
2010-01-27 18:29:49 +00:00
|
|
|
if (ast_opt_lock_confdir) {
|
|
|
|
ast_unlock_path(ast_config_AST_CONFIG_DIR);
|
|
|
|
}
|
2016-06-27 19:26:54 +00:00
|
|
|
goto module_reload_done;
|
2007-02-08 13:50:33 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
2006-08-21 02:11:39 +00:00
|
|
|
const struct ast_module_info *info = cur->info;
|
|
|
|
|
|
|
|
if (name && resource_name_match(name, cur->resource))
|
|
|
|
continue;
|
|
|
|
|
2008-02-15 19:50:47 +00:00
|
|
|
if (!cur->flags.running || cur->flags.declined) {
|
2013-05-24 20:44:07 +00:00
|
|
|
if (res == AST_MODULE_RELOAD_NOT_FOUND) {
|
|
|
|
res = AST_MODULE_RELOAD_UNINITIALIZED;
|
|
|
|
}
|
|
|
|
if (!name) {
|
2008-02-15 19:50:47 +00:00
|
|
|
continue;
|
2013-05-24 20:44:07 +00:00
|
|
|
}
|
2008-02-15 19:50:47 +00:00
|
|
|
break;
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
if (!info->reload) { /* cannot be reloaded */
|
2013-05-24 20:44:07 +00:00
|
|
|
if (res == AST_MODULE_RELOAD_NOT_FOUND) {
|
|
|
|
res = AST_MODULE_RELOAD_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
if (!name) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(3, "Reloading module '%s' (%s)\n", cur->resource, info->description);
|
2013-05-24 20:44:07 +00:00
|
|
|
if (info->reload() == AST_MODULE_LOAD_SUCCESS) {
|
|
|
|
res = AST_MODULE_RELOAD_SUCCESS;
|
|
|
|
}
|
|
|
|
if (name) {
|
|
|
|
break;
|
2012-08-16 22:45:33 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2010-01-27 18:29:49 +00:00
|
|
|
if (ast_opt_lock_confdir) {
|
|
|
|
ast_unlock_path(ast_config_AST_CONFIG_DIR);
|
|
|
|
}
|
2016-06-27 19:26:54 +00:00
|
|
|
module_reload_done:
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_mutex_unlock(&reloadlock);
|
2016-06-27 19:26:54 +00:00
|
|
|
ast_sd_notify("READY=1");
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2013-05-24 20:44:07 +00:00
|
|
|
module_reload_exit:
|
|
|
|
publish_reload_message(name, res);
|
2006-08-21 02:11:39 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int inspect_module(const struct ast_module *mod)
|
|
|
|
{
|
|
|
|
if (!mod->info->description) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' does not provide a description.\n", mod->resource);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!mod->info->key) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' does not provide a license key.\n", mod->resource);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (verify_key((unsigned char *) mod->info->key)) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' did not provide a valid license key.\n", mod->resource);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2007-11-20 19:28:10 +00:00
|
|
|
if (!ast_strlen_zero(mod->info->buildopt_sum) &&
|
|
|
|
strcmp(buildopt_sum, mod->info->buildopt_sum)) {
|
2007-11-16 16:56:59 +00:00
|
|
|
ast_log(LOG_WARNING, "Module '%s' was not compiled with the same compile-time options as this version of Asterisk.\n", mod->resource);
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' will not be initialized as it may cause instability.\n", mod->resource);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
static enum ast_module_load_result start_resource(struct ast_module *mod)
|
|
|
|
{
|
|
|
|
char tmp[256];
|
|
|
|
enum ast_module_load_result res;
|
|
|
|
|
2012-09-27 16:53:19 +00:00
|
|
|
if (mod->flags.running) {
|
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
if (!mod->info->load) {
|
|
|
|
return AST_MODULE_LOAD_FAILURE;
|
|
|
|
}
|
|
|
|
|
2013-04-26 21:31:39 +00:00
|
|
|
if (!ast_fully_booted) {
|
|
|
|
ast_verb(1, "Loading %s.\n", mod->resource);
|
|
|
|
}
|
2009-06-09 16:22:04 +00:00
|
|
|
res = mod->info->load();
|
|
|
|
|
|
|
|
switch (res) {
|
|
|
|
case AST_MODULE_LOAD_SUCCESS:
|
|
|
|
if (!ast_fully_booted) {
|
2014-05-28 22:54:12 +00:00
|
|
|
ast_verb(2, "%s => (%s)\n", mod->resource, term_color(tmp, mod->info->description, COLOR_BROWN, COLOR_BLACK, sizeof(tmp)));
|
2009-06-09 16:22:04 +00:00
|
|
|
} else {
|
|
|
|
ast_verb(1, "Loaded %s => (%s)\n", mod->resource, mod->info->description);
|
|
|
|
}
|
|
|
|
|
|
|
|
mod->flags.running = 1;
|
|
|
|
|
|
|
|
ast_update_use_count();
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_DECLINE:
|
|
|
|
mod->flags.declined = 1;
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_FAILURE:
|
2009-06-22 15:33:35 +00:00
|
|
|
case AST_MODULE_LOAD_SKIP: /* modules should never return this value */
|
|
|
|
case AST_MODULE_LOAD_PRIORITY:
|
2009-06-09 16:22:04 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
/* Make sure the newly started module is at the end of the list */
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
AST_DLLIST_REMOVE(&module_list, mod, entry);
|
|
|
|
AST_DLLIST_INSERT_TAIL(&module_list, mod, entry);
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! loads a resource based upon resource_name. If global_symbols_only is set
|
|
|
|
* only modules with global symbols will be loaded.
|
|
|
|
*
|
|
|
|
* If the ast_heap is provided (not NULL) the module is found and added to the
|
|
|
|
* heap without running the module's load() function. By doing this, modules
|
2012-03-22 19:51:16 +00:00
|
|
|
* added to the resource_heap can be initialized later in order by priority.
|
2009-06-09 16:22:04 +00:00
|
|
|
*
|
|
|
|
* If the ast_heap is not provided, the module's load function will be executed
|
|
|
|
* immediately */
|
2016-01-23 21:50:57 +00:00
|
|
|
static enum ast_module_load_result load_resource(const char *resource_name, unsigned int global_symbols_only, unsigned int suppress_logging, struct ast_heap *resource_heap, int required)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
|
|
|
enum ast_module_load_result res = AST_MODULE_LOAD_SUCCESS;
|
|
|
|
|
|
|
|
if ((mod = find_resource(resource_name, 0))) {
|
2007-05-03 16:43:49 +00:00
|
|
|
if (mod->flags.running) {
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_log(LOG_WARNING, "Module '%s' already exists.\n", resource_name);
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
if (global_symbols_only && !ast_test_flag(mod->info, AST_MODFLAG_GLOBAL_SYMBOLS))
|
|
|
|
return AST_MODULE_LOAD_SKIP;
|
|
|
|
} else {
|
2016-01-23 21:50:57 +00:00
|
|
|
mod = load_dynamic_module(resource_name, global_symbols_only, suppress_logging, resource_heap);
|
|
|
|
if (mod == MODULE_LOCAL_ONLY) {
|
|
|
|
return AST_MODULE_LOAD_SKIP;
|
|
|
|
}
|
|
|
|
if (!mod) {
|
2006-08-21 02:11:39 +00:00
|
|
|
if (!global_symbols_only) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' could not be loaded.\n", resource_name);
|
|
|
|
}
|
2016-01-23 21:50:57 +00:00
|
|
|
return required ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_DECLINE;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (inspect_module(mod)) {
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' could not be loaded.\n", resource_name);
|
|
|
|
unload_dynamic_module(mod);
|
2009-11-13 08:52:28 +00:00
|
|
|
return required ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_DECLINE;
|
2007-02-22 02:36:00 +00:00
|
|
|
}
|
|
|
|
|
2007-05-03 16:43:49 +00:00
|
|
|
mod->flags.declined = 0;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
if (resource_heap) {
|
|
|
|
ast_heap_push(resource_heap, mod);
|
2009-06-22 15:33:35 +00:00
|
|
|
res = AST_MODULE_LOAD_PRIORITY;
|
2009-06-09 16:22:04 +00:00
|
|
|
} else {
|
|
|
|
res = start_resource(mod);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ast_load_resource(const char *resource_name)
|
|
|
|
{
|
2008-06-05 15:58:11 +00:00
|
|
|
int res;
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
2016-01-23 21:50:57 +00:00
|
|
|
res = load_resource(resource_name, 0, 0, NULL, 0);
|
2012-08-16 22:45:33 +00:00
|
|
|
if (!res) {
|
|
|
|
ast_test_suite_event_notify("MODULE_LOAD", "Message: %s", resource_name);
|
|
|
|
}
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2008-06-05 15:58:11 +00:00
|
|
|
return res;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct load_order_entry {
|
|
|
|
char *resource;
|
2009-11-13 08:52:28 +00:00
|
|
|
int required;
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_ENTRY(load_order_entry) entry;
|
|
|
|
};
|
|
|
|
|
|
|
|
AST_LIST_HEAD_NOLOCK(load_order, load_order_entry);
|
|
|
|
|
2009-11-13 08:52:28 +00:00
|
|
|
static struct load_order_entry *add_to_load_order(const char *resource, struct load_order *load_order, int required)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct load_order_entry *order;
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE(load_order, order, entry) {
|
2009-11-13 08:52:28 +00:00
|
|
|
if (!resource_name_match(order->resource, resource)) {
|
2012-03-22 19:51:16 +00:00
|
|
|
/* Make sure we have the proper setting for the required field
|
2009-11-13 08:52:28 +00:00
|
|
|
(we might have both load= and required= lines in modules.conf) */
|
2009-11-13 10:53:14 +00:00
|
|
|
order->required |= required;
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
2009-11-13 08:52:28 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(order = ast_calloc(1, sizeof(*order))))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
order->resource = ast_strdup(resource);
|
2009-11-13 08:52:28 +00:00
|
|
|
order->required = required;
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_INSERT_TAIL(load_order, order, entry);
|
|
|
|
|
|
|
|
return order;
|
|
|
|
}
|
2008-06-12 17:27:55 +00:00
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
static int mod_load_cmp(void *a, void *b)
|
|
|
|
{
|
|
|
|
struct ast_module *a_mod = (struct ast_module *) a;
|
|
|
|
struct ast_module *b_mod = (struct ast_module *) b;
|
2013-05-01 20:35:25 +00:00
|
|
|
/* if load_pri is not set, default is 128. Lower is better */
|
|
|
|
int a_pri = ast_test_flag(a_mod->info, AST_MODFLAG_LOAD_ORDER) ? a_mod->info->load_pri : 128;
|
|
|
|
int b_pri = ast_test_flag(b_mod->info, AST_MODFLAG_LOAD_ORDER) ? b_mod->info->load_pri : 128;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns comparison values for a min-heap
|
|
|
|
* <0 a_pri > b_pri
|
|
|
|
* =0 a_pri == b_pri
|
|
|
|
* >0 a_pri < b_pri
|
|
|
|
*/
|
|
|
|
return b_pri - a_pri;
|
2009-06-09 16:22:04 +00:00
|
|
|
}
|
|
|
|
|
2016-01-23 21:50:57 +00:00
|
|
|
AST_LIST_HEAD_NOLOCK(load_retries, load_order_entry);
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*! loads modules in order by load_pri, updates mod_count
|
2009-11-13 08:52:28 +00:00
|
|
|
\return -1 on failure to load module, -2 on failure to load required module, otherwise 0
|
|
|
|
*/
|
2009-06-09 16:22:04 +00:00
|
|
|
static int load_resource_list(struct load_order *load_order, unsigned int global_symbols, int *mod_count)
|
|
|
|
{
|
|
|
|
struct ast_heap *resource_heap;
|
|
|
|
struct load_order_entry *order;
|
|
|
|
struct ast_module *mod;
|
2016-01-23 21:50:57 +00:00
|
|
|
struct load_retries load_retries;
|
2009-06-09 16:22:04 +00:00
|
|
|
int count = 0;
|
|
|
|
int res = 0;
|
2016-01-23 21:50:57 +00:00
|
|
|
int i = 0;
|
|
|
|
#define LOAD_RETRIES 4
|
|
|
|
|
|
|
|
AST_LIST_HEAD_INIT_NOLOCK(&load_retries);
|
2009-06-09 16:22:04 +00:00
|
|
|
|
|
|
|
if(!(resource_heap = ast_heap_create(8, mod_load_cmp, -1))) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* first, add find and add modules to heap */
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(load_order, order, entry) {
|
2016-01-23 21:50:57 +00:00
|
|
|
enum ast_module_load_result lres;
|
|
|
|
|
|
|
|
/* Suppress log messages unless this is the last pass */
|
|
|
|
lres = load_resource(order->resource, global_symbols, 1, resource_heap, order->required);
|
|
|
|
ast_debug(3, "PASS 0: %-46s %d %d\n", order->resource, lres, global_symbols);
|
|
|
|
switch (lres) {
|
2009-06-09 16:22:04 +00:00
|
|
|
case AST_MODULE_LOAD_SUCCESS:
|
2016-01-23 21:50:57 +00:00
|
|
|
/* We're supplying a heap so SUCCESS isn't possible but we still have to test for it. */
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_FAILURE:
|
2009-06-09 16:22:04 +00:00
|
|
|
case AST_MODULE_LOAD_DECLINE:
|
2016-01-23 21:50:57 +00:00
|
|
|
/*
|
|
|
|
* DECLINE or FAILURE means there was an issue with dlopen or module_register
|
|
|
|
* which might be retryable. LOAD_FAILURE only happens for required modules
|
|
|
|
* but we're still going to retry. We need to remove the entry from the
|
|
|
|
* load_order list and add it to the load_retries list.
|
|
|
|
*/
|
2009-06-09 16:22:04 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
2016-01-23 21:50:57 +00:00
|
|
|
AST_LIST_INSERT_TAIL(&load_retries, order, entry);
|
2009-06-09 16:22:04 +00:00
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_SKIP:
|
2016-01-23 21:50:57 +00:00
|
|
|
/*
|
|
|
|
* SKIP means that dlopen worked but global_symbols was set and this module doesn't qualify.
|
|
|
|
* Leave it in load_order for the next call of load_resource_list.
|
|
|
|
*/
|
2009-06-09 16:22:04 +00:00
|
|
|
break;
|
2009-06-22 15:33:35 +00:00
|
|
|
case AST_MODULE_LOAD_PRIORITY:
|
2016-01-23 21:50:57 +00:00
|
|
|
/* load_resource worked and the module was added to the priority heap */
|
2009-06-22 15:33:35 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
2013-06-12 02:29:08 +00:00
|
|
|
ast_free(order->resource);
|
|
|
|
ast_free(order);
|
2009-06-22 15:33:35 +00:00
|
|
|
break;
|
2009-06-09 16:22:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
|
2016-01-23 21:50:57 +00:00
|
|
|
/* Retry the failures until the list is empty or we reach LOAD_RETRIES */
|
|
|
|
for (i = 0; !AST_LIST_EMPTY(&load_retries) && i < LOAD_RETRIES; i++) {
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&load_retries, order, entry) {
|
|
|
|
enum ast_module_load_result lres;
|
|
|
|
|
|
|
|
/* Suppress log messages unless this is the last pass */
|
|
|
|
lres = load_resource(order->resource, global_symbols, (i < LOAD_RETRIES - 1), resource_heap, order->required);
|
|
|
|
ast_debug(3, "PASS %d %-46s %d %d\n", i + 1, order->resource, lres, global_symbols);
|
|
|
|
switch (lres) {
|
|
|
|
/* These are all retryable. */
|
|
|
|
case AST_MODULE_LOAD_SUCCESS:
|
|
|
|
case AST_MODULE_LOAD_DECLINE:
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_FAILURE:
|
|
|
|
/* LOAD_FAILURE only happens for required modules */
|
|
|
|
if (i == LOAD_RETRIES - 1) {
|
|
|
|
/* This was the last chance to load a required module*/
|
|
|
|
ast_log(LOG_ERROR, "*** Failed to load module %s - Required\n", order->resource);
|
|
|
|
fprintf(stderr, "*** Failed to load module %s - Required\n", order->resource);
|
|
|
|
res = -2;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
break;;
|
|
|
|
case AST_MODULE_LOAD_SKIP:
|
|
|
|
/*
|
|
|
|
* SKIP means that dlopen worked but global_symbols was set and this module
|
|
|
|
* doesn't qualify. Put it back in load_order for the next call of
|
|
|
|
* load_resource_list.
|
|
|
|
*/
|
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
|
|
|
AST_LIST_INSERT_TAIL(load_order, order, entry);
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_PRIORITY:
|
|
|
|
/* load_resource worked and the module was added to the priority heap */
|
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
|
|
|
ast_free(order->resource);
|
|
|
|
ast_free(order);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
}
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
/* second remove modules from heap sorted by priority */
|
|
|
|
while ((mod = ast_heap_pop(resource_heap))) {
|
2016-01-23 21:50:57 +00:00
|
|
|
enum ast_module_load_result lres;
|
|
|
|
|
|
|
|
lres = start_resource(mod);
|
|
|
|
ast_debug(3, "START: %-46s %d %d\n", mod->resource, lres, global_symbols);
|
|
|
|
switch (lres) {
|
2009-06-09 16:22:04 +00:00
|
|
|
case AST_MODULE_LOAD_SUCCESS:
|
|
|
|
count++;
|
|
|
|
case AST_MODULE_LOAD_DECLINE:
|
|
|
|
break;
|
|
|
|
case AST_MODULE_LOAD_FAILURE:
|
2017-04-11 16:07:39 +00:00
|
|
|
ast_log(LOG_ERROR, "*** Failed to load module %s\n", mod->resource);
|
2009-06-09 16:22:04 +00:00
|
|
|
res = -1;
|
|
|
|
goto done;
|
|
|
|
case AST_MODULE_LOAD_SKIP:
|
2009-06-22 15:33:35 +00:00
|
|
|
case AST_MODULE_LOAD_PRIORITY:
|
2009-06-09 16:22:04 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
2016-01-23 21:50:57 +00:00
|
|
|
|
|
|
|
while ((order = AST_LIST_REMOVE_HEAD(&load_retries, entry))) {
|
|
|
|
ast_free(order->resource);
|
|
|
|
ast_free(order);
|
|
|
|
}
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
if (mod_count) {
|
|
|
|
*mod_count += count;
|
|
|
|
}
|
|
|
|
ast_heap_destroy(resource_heap);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2006-08-21 22:23:26 +00:00
|
|
|
int load_modules(unsigned int preload_only)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct ast_config *cfg;
|
|
|
|
struct load_order_entry *order;
|
|
|
|
struct ast_variable *v;
|
|
|
|
unsigned int load_count;
|
|
|
|
struct load_order load_order;
|
|
|
|
int res = 0;
|
2007-08-16 21:09:46 +00:00
|
|
|
struct ast_flags config_flags = { 0 };
|
2007-11-27 21:04:29 +00:00
|
|
|
int modulecount = 0;
|
2006-08-21 03:06:41 +00:00
|
|
|
struct dirent *dirent;
|
|
|
|
DIR *dir;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(1, "Asterisk Dynamic Loader Starting:\n");
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2007-05-03 16:43:49 +00:00
|
|
|
AST_LIST_HEAD_INIT_NOLOCK(&load_order);
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2008-09-12 23:30:03 +00:00
|
|
|
cfg = ast_config_load2(AST_MODULE_CONFIG, "" /* core, can't reload */, config_flags);
|
|
|
|
if (cfg == CONFIG_STATUS_FILEMISSING || cfg == CONFIG_STATUS_FILEINVALID) {
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_log(LOG_WARNING, "No '%s' found, no modules will be loaded.\n", AST_MODULE_CONFIG);
|
2007-05-03 16:43:49 +00:00
|
|
|
goto done;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2006-08-22 23:06:13 +00:00
|
|
|
/* first, find all the modules we have been explicitly requested to load */
|
|
|
|
for (v = ast_variable_browse(cfg, "modules"); v; v = v->next) {
|
2008-06-12 17:27:55 +00:00
|
|
|
if (!strcasecmp(v->name, preload_only ? "preload" : "load")) {
|
2009-11-13 08:52:28 +00:00
|
|
|
add_to_load_order(v->value, &load_order, 0);
|
|
|
|
}
|
|
|
|
if (!strcasecmp(v->name, preload_only ? "preload-require" : "require")) {
|
|
|
|
/* Add the module to the list and make sure it's required */
|
|
|
|
add_to_load_order(v->value, &load_order, 1);
|
|
|
|
ast_debug(2, "Adding module to required list: %s (%s)\n", v->value, v->name);
|
2008-06-12 17:27:55 +00:00
|
|
|
}
|
2009-11-13 08:52:28 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* check if 'autoload' is on */
|
2006-08-21 22:23:26 +00:00
|
|
|
if (!preload_only && ast_true(ast_variable_retrieve(cfg, "modules", "autoload"))) {
|
2006-08-21 02:11:39 +00:00
|
|
|
/* if we are allowed to load dynamic modules, scan the directory for
|
|
|
|
for all available modules and add them as well */
|
2012-06-11 15:23:30 +00:00
|
|
|
if ((dir = opendir(ast_config_AST_MODULE_DIR))) {
|
2006-08-21 02:11:39 +00:00
|
|
|
while ((dirent = readdir(dir))) {
|
|
|
|
int ld = strlen(dirent->d_name);
|
2006-09-15 05:00:27 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
/* Must end in .so to load it. */
|
|
|
|
|
|
|
|
if (ld < 4)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (strcasecmp(dirent->d_name + ld - 3, ".so"))
|
2007-05-03 16:43:49 +00:00
|
|
|
continue;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2007-05-03 16:43:49 +00:00
|
|
|
/* if there is already a module by this name in the module_list,
|
|
|
|
skip this file */
|
|
|
|
if (find_resource(dirent->d_name, 0))
|
|
|
|
continue;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2009-11-13 08:52:28 +00:00
|
|
|
add_to_load_order(dirent->d_name, &load_order, 0);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
closedir(dir);
|
|
|
|
} else {
|
|
|
|
if (!ast_opt_quiet)
|
|
|
|
ast_log(LOG_WARNING, "Unable to open modules directory '%s'.\n",
|
|
|
|
ast_config_AST_MODULE_DIR);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* now scan the config for any modules we are prohibited from loading and
|
|
|
|
remove them from the load order */
|
|
|
|
for (v = ast_variable_browse(cfg, "modules"); v; v = v->next) {
|
|
|
|
if (strcasecmp(v->name, "noload"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&load_order, order, entry) {
|
2008-07-28 16:42:00 +00:00
|
|
|
if (!resource_name_match(order->resource, v->value)) {
|
2007-11-08 05:28:47 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(order->resource);
|
|
|
|
ast_free(order);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we are done with the config now, all the information we need is in the
|
|
|
|
load_order list */
|
|
|
|
ast_config_destroy(cfg);
|
|
|
|
|
|
|
|
load_count = 0;
|
|
|
|
AST_LIST_TRAVERSE(&load_order, order, entry)
|
|
|
|
load_count++;
|
|
|
|
|
2006-08-22 23:06:13 +00:00
|
|
|
if (load_count)
|
2014-05-09 22:49:26 +00:00
|
|
|
ast_log(LOG_NOTICE, "%u modules will be loaded.\n", load_count);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
/* first, load only modules that provide global symbols */
|
2009-06-09 16:22:04 +00:00
|
|
|
if ((res = load_resource_list(&load_order, 1, &modulecount)) < 0) {
|
|
|
|
goto done;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* now load everything else */
|
2009-06-09 16:22:04 +00:00
|
|
|
if ((res = load_resource_list(&load_order, 0, &modulecount)) < 0) {
|
|
|
|
goto done;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
|
|
|
while ((order = AST_LIST_REMOVE_HEAD(&load_order, entry))) {
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(order->resource);
|
|
|
|
ast_free(order);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2006-08-21 02:11:39 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_update_use_count(void)
|
|
|
|
{
|
2006-09-15 05:00:27 +00:00
|
|
|
/* Notify any module monitors that the use count for a
|
2006-08-21 02:11:39 +00:00
|
|
|
resource has changed */
|
|
|
|
struct loadupdate *m;
|
|
|
|
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_LOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_TRAVERSE(&updaters, m, entry)
|
|
|
|
m->updater();
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_UNLOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2014-07-25 16:47:17 +00:00
|
|
|
int ast_update_module_list(int (*modentry)(const char *module, const char *description,
|
|
|
|
int usecnt, const char *status, const char *like,
|
|
|
|
enum ast_module_support_level support_level),
|
|
|
|
const char *like)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
int unlock = -1;
|
|
|
|
int total_mod_loaded = 0;
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_LIST_HEAD_NOLOCK(, ast_module) alpha_module_list = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
if (AST_DLLIST_TRYLOCK(&module_list)) {
|
2006-08-21 02:11:39 +00:00
|
|
|
unlock = 0;
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
|
|
|
AST_LIST_INSERT_SORTALPHA(&alpha_module_list, cur, list_entry, resource);
|
|
|
|
}
|
|
|
|
|
2014-07-25 18:09:40 +00:00
|
|
|
while ((cur = AST_LIST_REMOVE_HEAD(&alpha_module_list, list_entry))) {
|
2013-02-19 17:17:10 +00:00
|
|
|
total_mod_loaded += modentry(cur->resource, cur->info->description, cur->usecount,
|
2014-07-25 16:47:17 +00:00
|
|
|
cur->flags.running ? "Running" : "Not Running", like, cur->info->support_level);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
module loader: Unload modules in reverse order of their start order
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 14:27:52 +00:00
|
|
|
if (unlock) {
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return total_mod_loaded;
|
|
|
|
}
|
|
|
|
|
2015-06-26 15:57:15 +00:00
|
|
|
int ast_update_module_list_data(int (*modentry)(const char *module, const char *description,
|
|
|
|
int usecnt, const char *status, const char *like,
|
|
|
|
enum ast_module_support_level support_level,
|
|
|
|
void *data),
|
|
|
|
const char *like, void *data)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
int total_mod_loaded = 0;
|
|
|
|
AST_LIST_HEAD_NOLOCK(, ast_module) alpha_module_list = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
|
|
|
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
|
|
|
AST_LIST_INSERT_SORTALPHA(&alpha_module_list, cur, list_entry, resource);
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((cur = AST_LIST_REMOVE_HEAD(&alpha_module_list, list_entry))) {
|
|
|
|
total_mod_loaded += modentry(cur->resource, cur->info->description, cur->usecount,
|
|
|
|
cur->flags.running? "Running" : "Not Running", like, cur->info->support_level, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
|
|
|
|
return total_mod_loaded;
|
|
|
|
}
|
|
|
|
|
2015-07-13 15:54:51 +00:00
|
|
|
int ast_update_module_list_condition(int (*modentry)(const char *module, const char *description,
|
|
|
|
int usecnt, const char *status,
|
|
|
|
const char *like,
|
|
|
|
enum ast_module_support_level support_level,
|
|
|
|
void *data, const char *condition),
|
|
|
|
const char *like, void *data, const char *condition)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
int conditions_met = 0;
|
|
|
|
AST_LIST_HEAD_NOLOCK(, ast_module) alpha_module_list = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
|
|
|
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
|
|
|
AST_LIST_INSERT_SORTALPHA(&alpha_module_list, cur, list_entry, resource);
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((cur = AST_LIST_REMOVE_HEAD(&alpha_module_list, list_entry))) {
|
|
|
|
conditions_met += modentry(cur->resource, cur->info->description, cur->usecount,
|
|
|
|
cur->flags.running? "Running" : "Not Running", like, cur->info->support_level, data,
|
|
|
|
condition);
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
|
|
|
|
return conditions_met;
|
|
|
|
}
|
|
|
|
|
2006-10-31 08:08:56 +00:00
|
|
|
/*! \brief Check if module exists */
|
2007-05-07 19:03:53 +00:00
|
|
|
int ast_module_check(const char *name)
|
2006-10-30 21:48:41 +00:00
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
|
|
|
|
if (ast_strlen_zero(name))
|
|
|
|
return 0; /* FALSE */
|
|
|
|
|
2006-10-31 08:08:56 +00:00
|
|
|
cur = find_resource(name, 1);
|
|
|
|
|
|
|
|
return (cur != NULL);
|
2006-10-30 21:48:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-09-15 05:00:27 +00:00
|
|
|
int ast_loader_register(int (*v)(void))
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2006-09-15 05:00:27 +00:00
|
|
|
struct loadupdate *tmp;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
if (!(tmp = ast_malloc(sizeof(*tmp))))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
tmp->updater = v;
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_LOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_INSERT_HEAD(&updaters, tmp, entry);
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_UNLOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ast_loader_unregister(int (*v)(void))
|
|
|
|
{
|
|
|
|
struct loadupdate *cur;
|
|
|
|
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_LOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&updaters, cur, entry) {
|
|
|
|
if (cur->updater == v) {
|
2007-11-08 05:28:47 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(entry);
|
2006-08-21 02:11:39 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
2008-02-27 17:12:08 +00:00
|
|
|
AST_LIST_UNLOCK(&updaters);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return cur ? 0 : -1;
|
|
|
|
}
|
|
|
|
|
2015-02-11 17:03:04 +00:00
|
|
|
struct ast_module *__ast_module_ref(struct ast_module *mod, const char *file, int line, const char *func)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2010-02-17 07:01:13 +00:00
|
|
|
if (!mod) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2015-04-17 07:16:59 +00:00
|
|
|
if (mod->ref_debug) {
|
|
|
|
__ao2_ref(mod->ref_debug, +1, "", file, line, func);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_atomic_fetchadd_int(&mod->usecount, +1);
|
|
|
|
ast_update_use_count();
|
|
|
|
|
|
|
|
return mod;
|
|
|
|
}
|
|
|
|
|
2015-02-11 17:03:04 +00:00
|
|
|
void __ast_module_shutdown_ref(struct ast_module *mod, const char *file, int line, const char *func)
|
|
|
|
{
|
2015-02-21 02:58:19 +00:00
|
|
|
if (!mod || mod->flags.keepuntilshutdown) {
|
|
|
|
return;
|
2015-02-11 17:03:04 +00:00
|
|
|
}
|
2015-02-21 02:58:19 +00:00
|
|
|
|
|
|
|
__ast_module_ref(mod, file, line, func);
|
|
|
|
mod->flags.keepuntilshutdown = 1;
|
2015-02-11 17:03:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void __ast_module_unref(struct ast_module *mod, const char *file, int line, const char *func)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2010-02-17 07:01:13 +00:00
|
|
|
if (!mod) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-04-17 07:16:59 +00:00
|
|
|
if (mod->ref_debug) {
|
|
|
|
__ao2_ref(mod->ref_debug, -1, "", file, line, func);
|
|
|
|
}
|
2015-02-11 17:03:04 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_atomic_fetchadd_int(&mod->usecount, -1);
|
|
|
|
ast_update_use_count();
|
|
|
|
}
|
2014-07-25 16:47:17 +00:00
|
|
|
|
|
|
|
const char *support_level_map [] = {
|
|
|
|
[AST_MODULE_SUPPORT_UNKNOWN] = "unknown",
|
|
|
|
[AST_MODULE_SUPPORT_CORE] = "core",
|
|
|
|
[AST_MODULE_SUPPORT_EXTENDED] = "extended",
|
|
|
|
[AST_MODULE_SUPPORT_DEPRECATED] = "deprecated",
|
|
|
|
};
|
|
|
|
|
|
|
|
const char *ast_module_support_level_to_string(enum ast_module_support_level support_level)
|
|
|
|
{
|
|
|
|
return support_level_map[support_level];
|
|
|
|
}
|