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>
|
2017-10-30 18:30:18 -04:00
|
|
|
#include <editline/readline.h>
|
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
|
|
|
#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"
|
2017-11-21 01:28:48 -05:00
|
|
|
#include "asterisk/vector.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
|
|
|
|
2017-11-21 01:28:48 -05:00
|
|
|
AST_VECTOR(module_vector, struct ast_module *);
|
|
|
|
|
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;
|
2017-11-19 22:23:44 -05:00
|
|
|
/*! Used to get module references into refs log */
|
2015-02-11 17:03:04 +00:00
|
|
|
void *ref_debug;
|
2017-11-19 22:23:44 -05:00
|
|
|
/*! The shared lib. */
|
|
|
|
void *lib;
|
|
|
|
/*! Number of 'users' and other references currently holding the module. */
|
|
|
|
int usecount;
|
|
|
|
/*! List of users holding the module. */
|
|
|
|
struct module_user_list users;
|
2007-05-03 16:43:49 +00:00
|
|
|
struct {
|
2017-11-19 22:23:44 -05:00
|
|
|
/*! The module running and ready to accept requests. */
|
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;
|
2017-11-19 22:23:44 -05:00
|
|
|
/*! The module has declined to start. */
|
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 declined:1;
|
2017-11-19 22:23:44 -05:00
|
|
|
/*! This module is being held open until it's time to shutdown. */
|
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_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
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
static int module_vector_strcasecmp(struct ast_module *a, struct ast_module *b)
|
|
|
|
{
|
|
|
|
return strcasecmp(a->resource, b->resource);
|
|
|
|
}
|
|
|
|
|
2017-11-21 01:28:48 -05:00
|
|
|
static int module_vector_cmp(struct ast_module *a, struct ast_module *b)
|
|
|
|
{
|
|
|
|
/* if load_pri is not set, default is 128. Lower is better */
|
|
|
|
int a_pri = ast_test_flag(a->info, AST_MODFLAG_LOAD_ORDER)
|
|
|
|
? a->info->load_pri : AST_MODPRI_DEFAULT;
|
|
|
|
int b_pri = ast_test_flag(b->info, AST_MODFLAG_LOAD_ORDER)
|
|
|
|
? b->info->load_pri : AST_MODPRI_DEFAULT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns comparison values for a vector sorted by priority.
|
|
|
|
* <0 a_pri < b_pri
|
|
|
|
* =0 a_pri == b_pri
|
|
|
|
* >0 a_pri > b_pri
|
|
|
|
*/
|
|
|
|
return a_pri - b_pri;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2017-11-21 21:34:56 -05:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
*
|
|
|
|
* This variable is set by load_dynamic_module so ast_module_register
|
|
|
|
* can know what pointer is being registered.
|
|
|
|
*
|
|
|
|
* This is protected by the module_list lock.
|
|
|
|
*/
|
2017-12-23 23:51:13 -05:00
|
|
|
static struct ast_module * volatile resource_being_loaded;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-11-21 21:34:56 -05:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Used by AST_MODULE_INFO to register with the module loader.
|
|
|
|
*
|
|
|
|
* This function is automatically called when each module is opened.
|
|
|
|
* It must never be used from outside AST_MODULE_INFO.
|
|
|
|
*/
|
2006-08-21 02:11:39 +00:00
|
|
|
void ast_module_register(const struct ast_module_info *info)
|
|
|
|
{
|
2017-11-21 21:34:56 -05:00
|
|
|
struct ast_module *mod;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This lock protects resource_being_loaded as well as the module
|
|
|
|
* list. Normally we already have a lock on module_list when we
|
|
|
|
* begin the load but locking again from here prevents corruption
|
|
|
|
* if an asterisk module is dlopen'ed from outside the module loader.
|
|
|
|
*/
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
mod = resource_being_loaded;
|
|
|
|
if (!mod) {
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
return;
|
|
|
|
}
|
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
|
|
|
|
2017-11-21 21:34:56 -05:00
|
|
|
/* This tells load_dynamic_module that we're registered. */
|
|
|
|
resource_being_loaded = NULL;
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
mod->info = info;
|
2015-04-17 03:16:59 -04: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);
|
|
|
|
|
2017-03-24 08:43:05 -04:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2017-11-21 21:34:56 -05:00
|
|
|
static void module_destroy(struct ast_module *mod)
|
|
|
|
{
|
|
|
|
AST_LIST_HEAD_DESTROY(&mod->users);
|
|
|
|
ao2_cleanup(mod->ref_debug);
|
|
|
|
ast_free(mod);
|
|
|
|
}
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
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);
|
2017-11-21 21:34:56 -05:00
|
|
|
module_destroy(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 03:16:59 -04: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 03:16:59 -04: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 03:16:59 -04: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;
|
|
|
|
}
|
|
|
|
|
2017-12-08 19:19:34 -05:00
|
|
|
static size_t resource_name_baselen(const char *name)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2017-12-08 19:19:34 -05:00
|
|
|
size_t len = strlen(name);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-12-08 19:19:34 -05:00
|
|
|
if (len > 3 && !strcasecmp(name + len - 3, ".so")) {
|
|
|
|
return len - 3;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
2017-12-08 19:19:34 -05:00
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int resource_name_match(const char *name1, size_t baselen1, const char *name2)
|
|
|
|
{
|
|
|
|
if (baselen1 != resource_name_baselen(name2)) {
|
|
|
|
return -1;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2017-12-08 19:19:34 -05:00
|
|
|
return strncasecmp(name1, name2, baselen1);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_module *find_resource(const char *resource, int do_lock)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
2017-12-08 19:19:34 -05:00
|
|
|
size_t resource_baselen = resource_name_baselen(resource);
|
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 (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) {
|
2017-12-08 19:19:34 -05:00
|
|
|
if (!resource_name_match(resource, resource_baselen, cur->resource)) {
|
2006-08-21 02:11:39 +00:00
|
|
|
break;
|
2017-12-08 19:19:34 -05: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
|
|
|
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 14:50:57 -07:00
|
|
|
#define MODULE_LOCAL_ONLY (void *)-1
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Attempt to dlopen a module.
|
|
|
|
*
|
|
|
|
* \param resource_in The module name to load.
|
|
|
|
* \param so_ext ".so" or blank if ".so" is already part of resource_in.
|
|
|
|
* \param filename Passed directly to dlopen.
|
|
|
|
* \param flags Passed directly to dlopen.
|
|
|
|
* \param suppress_logging Do not log any error from dlopen.
|
|
|
|
*
|
|
|
|
* \return Pointer to opened module, NULL on error.
|
|
|
|
*
|
|
|
|
* \warning module_list must be locked before calling this function.
|
|
|
|
*/
|
|
|
|
static struct ast_module *load_dlopen(const char *resource_in, const char *so_ext,
|
|
|
|
const char *filename, int flags, unsigned int suppress_logging)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
|
|
|
|
2017-11-21 21:34:56 -05:00
|
|
|
ast_assert(!resource_being_loaded);
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
mod = ast_calloc(1, sizeof(*mod) + strlen(resource_in) + strlen(so_ext) + 1);
|
|
|
|
if (!mod) {
|
|
|
|
return NULL;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
sprintf(mod->resource, "%s%s", resource_in, so_ext); /* safe */
|
2006-08-21 14:42:03 +00:00
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
resource_being_loaded = mod;
|
|
|
|
mod->lib = dlopen(filename, flags);
|
2017-11-21 21:34:56 -05:00
|
|
|
if (resource_being_loaded) {
|
|
|
|
resource_being_loaded = NULL;
|
2017-11-21 00:10:58 -05:00
|
|
|
if (mod->lib) {
|
2017-11-21 21:34:56 -05:00
|
|
|
ast_log(LOG_ERROR, "Module '%s' did not register itself during load\n", resource_in);
|
2017-11-21 00:10:58 -05:00
|
|
|
logged_dlclose(resource_in, mod->lib);
|
2017-11-21 21:34:56 -05:00
|
|
|
} else if (!suppress_logging) {
|
2016-01-23 14:50:57 -07:00
|
|
|
ast_log(LOG_WARNING, "Error loading module '%s': %s\n", resource_in, dlerror());
|
|
|
|
}
|
2017-11-21 21:34:56 -05:00
|
|
|
ast_free(mod);
|
2017-11-21 00:10:58 -05:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
return mod;
|
|
|
|
}
|
2006-08-21 14:42:03 +00:00
|
|
|
|
2017-11-21 01:28:48 -05:00
|
|
|
static struct ast_module *load_dynamic_module(const char *resource_in, unsigned int global_symbols_only, unsigned int suppress_logging)
|
2017-11-21 00:10:58 -05:00
|
|
|
{
|
|
|
|
char fn[PATH_MAX];
|
|
|
|
struct ast_module *mod;
|
|
|
|
size_t resource_in_len = strlen(resource_in);
|
|
|
|
int exports_globals;
|
|
|
|
const char *so_ext = "";
|
|
|
|
|
|
|
|
if (resource_in_len < 4 || strcasecmp(resource_in + resource_in_len - 3, ".so")) {
|
|
|
|
so_ext = ".so";
|
2006-08-23 19:28:13 +00:00
|
|
|
}
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
snprintf(fn, sizeof(fn), "%s/%s%s", ast_config_AST_MODULE_DIR, resource_in, so_ext);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
/* Try loading in quiet mode first with flags to export global symbols.
|
|
|
|
* If the module does not want to export globals we will close and reopen. */
|
|
|
|
mod = load_dlopen(resource_in, so_ext, fn,
|
|
|
|
global_symbols_only ? RTLD_NOW | RTLD_GLOBAL : RTLD_NOW | RTLD_LOCAL,
|
|
|
|
suppress_logging);
|
2006-08-21 14:42:03 +00:00
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
if (!mod) {
|
2006-08-21 14:42:03 +00:00
|
|
|
return NULL;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
exports_globals = ast_test_flag(mod->info, AST_MODFLAG_GLOBAL_SYMBOLS);
|
|
|
|
if ((global_symbols_only && exports_globals) || (!global_symbols_only && !exports_globals)) {
|
|
|
|
/* The first dlopen had the correct flags. */
|
|
|
|
return mod;
|
|
|
|
}
|
2006-08-23 19:28:13 +00:00
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
/* Close the module so we can reopen with correct flags. */
|
|
|
|
logged_dlclose(resource_in, mod->lib);
|
|
|
|
if (global_symbols_only) {
|
|
|
|
return MODULE_LOCAL_ONLY;
|
|
|
|
}
|
2006-08-21 14:42:03 +00:00
|
|
|
|
2017-11-21 00:10:58 -05:00
|
|
|
return load_dlopen(resource_in, so_ext, fn,
|
|
|
|
exports_globals ? RTLD_NOW | RTLD_GLOBAL : RTLD_NOW | RTLD_LOCAL,
|
|
|
|
0);
|
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-27 22:49:43 -04: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();
|
|
|
|
}
|
2017-11-21 21:34:56 -05:00
|
|
|
module_destroy(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-27 22:49:43 -04: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-27 22:49:43 -04: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 08:43:05 -04:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2017-10-30 18:30:18 -04:00
|
|
|
static int module_matches_helper_type(struct ast_module *mod, enum ast_module_helper_type type)
|
2006-08-21 02:11:39 +00:00
|
|
|
{
|
2017-10-30 18:30:18 -04:00
|
|
|
switch (type) {
|
|
|
|
case AST_MODULE_HELPER_UNLOAD:
|
|
|
|
return !mod->usecount && mod->flags.running && !mod->flags.declined;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-10-30 18:30:18 -04:00
|
|
|
case AST_MODULE_HELPER_RELOAD:
|
|
|
|
return mod->flags.running && mod->info->reload;
|
|
|
|
|
|
|
|
case AST_MODULE_HELPER_RUNNING:
|
|
|
|
return mod->flags.running;
|
|
|
|
|
|
|
|
case AST_MODULE_HELPER_LOADED:
|
|
|
|
/* if we have a 'struct ast_module' then we're loaded. */
|
|
|
|
return 1;
|
|
|
|
default:
|
|
|
|
/* This function is not called for AST_MODULE_HELPER_LOAD. */
|
|
|
|
/* Unknown ast_module_helper_type. Assume it doesn't match. */
|
|
|
|
ast_assert(0);
|
|
|
|
|
|
|
|
return 0;
|
2017-10-30 01:32:32 -04:00
|
|
|
}
|
2017-10-30 18:30:18 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *module_load_helper(const char *word, int state)
|
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
|
|
|
int which = 0;
|
|
|
|
char *name;
|
|
|
|
char *ret = NULL;
|
|
|
|
char *editline_ret;
|
|
|
|
char fullpath[PATH_MAX];
|
|
|
|
int idx = 0;
|
|
|
|
/* This is needed to avoid listing modules that are already running. */
|
|
|
|
AST_VECTOR(, char *) running_modules;
|
|
|
|
|
|
|
|
AST_VECTOR_INIT(&running_modules, 200);
|
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);
|
2017-10-30 18:30:18 -04:00
|
|
|
AST_DLLIST_TRAVERSE(&module_list, mod, entry) {
|
|
|
|
if (mod->flags.running) {
|
|
|
|
AST_VECTOR_APPEND(&running_modules, mod->resource);
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
2017-10-30 18:30:18 -04:00
|
|
|
|
|
|
|
if (word[0] == '/') {
|
|
|
|
/* BUGBUG: we should not support this. */
|
|
|
|
ast_copy_string(fullpath, word, sizeof(fullpath));
|
|
|
|
} else {
|
|
|
|
snprintf(fullpath, sizeof(fullpath), "%s/%s", ast_config_AST_MODULE_DIR, word);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is ugly that we keep calling filename_completion_function.
|
|
|
|
* The only way to avoid this would be to make a copy of the function
|
|
|
|
* that skips matches found in the running_modules vector.
|
|
|
|
*/
|
|
|
|
while (!ret && (name = editline_ret = filename_completion_function(fullpath, idx++))) {
|
|
|
|
if (word[0] != '/') {
|
|
|
|
name += (strlen(ast_config_AST_MODULE_DIR) + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't list files that are already loaded! */
|
|
|
|
if (!AST_VECTOR_GET_CMP(&running_modules, name, !strcasecmp) && ++which > state) {
|
|
|
|
ret = ast_strdup(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_std_free(editline_ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Do not clean-up the elements, they belong to module_list. */
|
|
|
|
AST_VECTOR_FREE(&running_modules);
|
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
|
|
|
|
2017-10-30 18:30:18 -04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *ast_module_helper(const char *line, const char *word, int pos, int state, int rpos, enum ast_module_helper_type type)
|
|
|
|
{
|
|
|
|
struct ast_module *mod;
|
|
|
|
int which = 0;
|
|
|
|
int wordlen = strlen(word);
|
|
|
|
char *ret = NULL;
|
|
|
|
|
|
|
|
if (pos != rpos) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type == AST_MODULE_HELPER_LOAD) {
|
|
|
|
return module_load_helper(word, state);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type == AST_MODULE_HELPER_RELOAD) {
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
for (idx = 0; reload_classes[idx].name; idx++) {
|
|
|
|
if (!strncasecmp(word, reload_classes[idx].name, wordlen) && ++which > state) {
|
|
|
|
return ast_strdup(reload_classes[idx].name);
|
2017-10-30 01:32:32 -04:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-30 18:30:18 -04:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, mod, entry) {
|
|
|
|
if (!module_matches_helper_type(mod, type)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strncasecmp(word, mod->resource, wordlen) && ++which > state) {
|
|
|
|
ret = ast_strdup(mod->resource);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
|
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 14:04:15 -04: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 14:04:15 -04: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;
|
2017-12-08 19:19:34 -05:00
|
|
|
size_t name_baselen = name ? resource_name_baselen(name) : 0;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
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 21:26:54 +02: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 21:26:54 +02: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 21:26:54 +02: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;
|
|
|
|
|
2017-12-08 19:19:34 -05:00
|
|
|
if (name && resource_name_match(name, name_baselen, cur->resource)) {
|
2006-08-21 02:11:39 +00:00
|
|
|
continue;
|
2017-12-08 19:19:34 -05:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
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 21:26:54 +02:00
|
|
|
module_reload_done:
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_mutex_unlock(&reloadlock);
|
2016-06-27 21:26:54 +02: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.
|
|
|
|
*
|
2017-11-21 01:28:48 -05:00
|
|
|
* If the module_vector is provided (not NULL) the module is found and added to the
|
|
|
|
* vector without running the module's load() function. By doing this, modules
|
|
|
|
* can be initialized later in order by priority and dependencies.
|
2009-06-09 16:22:04 +00:00
|
|
|
*
|
2017-11-21 01:28:48 -05:00
|
|
|
* If the module_vector is not provided, the module's load function will be executed
|
2009-06-09 16:22:04 +00:00
|
|
|
* immediately */
|
2017-11-21 01:28:48 -05:00
|
|
|
static enum ast_module_load_result load_resource(const char *resource_name, unsigned int global_symbols_only, unsigned int suppress_logging, struct module_vector *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 {
|
2017-11-21 01:28:48 -05:00
|
|
|
mod = load_dynamic_module(resource_name, global_symbols_only, suppress_logging);
|
2016-01-23 14:50:57 -07:00
|
|
|
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 14:50:57 -07:00
|
|
|
return required ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_DECLINE;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (inspect_module(mod)) {
|
2017-11-21 01:28:48 -05:00
|
|
|
goto prestart_error;
|
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) {
|
2017-11-21 01:28:48 -05:00
|
|
|
if (AST_VECTOR_ADD_SORTED(resource_heap, mod, module_vector_cmp)) {
|
|
|
|
goto prestart_error;
|
|
|
|
}
|
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;
|
2017-11-21 01:28:48 -05:00
|
|
|
|
|
|
|
prestart_error:
|
|
|
|
ast_log(LOG_WARNING, "Module '%s' could not be loaded.\n", resource_name);
|
|
|
|
unload_dynamic_module(mod);
|
|
|
|
return required ? AST_MODULE_LOAD_FAILURE : AST_MODULE_LOAD_DECLINE;
|
2006-08-21 02:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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 14:50:57 -07: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;
|
2017-12-08 19:19:34 -05:00
|
|
|
size_t resource_baselen = resource_name_baselen(resource);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
AST_LIST_TRAVERSE(load_order, order, entry) {
|
2017-12-08 19:19:34 -05:00
|
|
|
if (!resource_name_match(resource, resource_baselen, order->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
|
|
|
|
2016-01-23 14:50:57 -07: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)
|
|
|
|
{
|
2017-11-21 01:28:48 -05:00
|
|
|
struct module_vector resource_heap;
|
2009-06-09 16:22:04 +00:00
|
|
|
struct load_order_entry *order;
|
2016-01-23 14:50:57 -07:00
|
|
|
struct load_retries load_retries;
|
2009-06-09 16:22:04 +00:00
|
|
|
int count = 0;
|
|
|
|
int res = 0;
|
2016-01-23 14:50:57 -07:00
|
|
|
int i = 0;
|
|
|
|
#define LOAD_RETRIES 4
|
|
|
|
|
|
|
|
AST_LIST_HEAD_INIT_NOLOCK(&load_retries);
|
2009-06-09 16:22:04 +00:00
|
|
|
|
2017-11-21 01:28:48 -05:00
|
|
|
if (AST_VECTOR_INIT(&resource_heap, 500)) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to initialize module loader.\n");
|
|
|
|
|
2009-06-09 16:22:04 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* first, add find and add modules to heap */
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(load_order, order, entry) {
|
2016-01-23 14:50:57 -07:00
|
|
|
enum ast_module_load_result lres;
|
|
|
|
|
|
|
|
/* Suppress log messages unless this is the last pass */
|
2017-11-21 01:28:48 -05:00
|
|
|
lres = load_resource(order->resource, global_symbols, 1, &resource_heap, order->required);
|
2016-01-23 14:50:57 -07:00
|
|
|
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 14:50:57 -07: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 14:50:57 -07: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 14:50:57 -07: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 14:50:57 -07: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:
|
2017-11-21 01:28:48 -05:00
|
|
|
/* load_resource worked and the module was added to the priority vector */
|
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 14:50:57 -07: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 */
|
2017-11-21 01:28:48 -05:00
|
|
|
lres = load_resource(order->resource, global_symbols, (i < LOAD_RETRIES - 1), &resource_heap, order->required);
|
2016-01-23 14:50:57 -07:00
|
|
|
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 */
|
2017-11-21 01:28:48 -05:00
|
|
|
for (i = 0; i < AST_VECTOR_SIZE(&resource_heap); i++) {
|
|
|
|
struct ast_module *mod = AST_VECTOR_GET(&resource_heap, i);
|
2016-01-23 14:50:57 -07: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 10:07:39 -06: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 14:50:57 -07: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;
|
|
|
|
}
|
2017-11-21 01:28:48 -05:00
|
|
|
AST_VECTOR_FREE(&resource_heap);
|
2009-06-09 16:22:04 +00:00
|
|
|
|
|
|
|
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) {
|
2017-12-08 19:19:34 -05:00
|
|
|
size_t baselen;
|
|
|
|
|
|
|
|
if (strcasecmp(v->name, "noload")) {
|
2006-08-21 02:11:39 +00:00
|
|
|
continue;
|
2017-12-08 19:19:34 -05:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-12-08 19:19:34 -05:00
|
|
|
baselen = resource_name_baselen(v->value);
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&load_order, order, entry) {
|
2017-12-08 19:19:34 -05:00
|
|
|
if (!resource_name_match(v->value, baselen, order->resource)) {
|
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
|
|
|
}
|
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Build an alpha sorted list of modules.
|
|
|
|
*
|
|
|
|
* \param alpha_module_list Pointer to uninitialized module_vector.
|
|
|
|
*
|
|
|
|
* This function always initializes alpha_module_list.
|
|
|
|
*
|
|
|
|
* \pre module_list must be locked.
|
|
|
|
*/
|
|
|
|
static int alpha_module_list_create(struct module_vector *alpha_module_list)
|
|
|
|
{
|
|
|
|
struct ast_module *cur;
|
|
|
|
|
|
|
|
if (AST_VECTOR_INIT(alpha_module_list, 32)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_DLLIST_TRAVERSE(&module_list, cur, entry) {
|
|
|
|
if (AST_VECTOR_ADD_SORTED(alpha_module_list, cur, module_vector_strcasecmp)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
|
|
|
int total_mod_loaded = 0;
|
2017-12-11 18:07:54 -05:00
|
|
|
struct module_vector alpha_module_list;
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
AST_DLLIST_LOCK(&module_list);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
if (!alpha_module_list_create(&alpha_module_list)) {
|
|
|
|
int idx;
|
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
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
for (idx = 0; idx < AST_VECTOR_SIZE(&alpha_module_list); idx++) {
|
|
|
|
struct ast_module *cur = AST_VECTOR_GET(&alpha_module_list, idx);
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
total_mod_loaded += modentry(cur->resource, cur->info->description, cur->usecount,
|
|
|
|
cur->flags.running ? "Running" : "Not Running", like, cur->info->support_level);
|
|
|
|
}
|
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
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
|
|
|
AST_VECTOR_FREE(&alpha_module_list);
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
return total_mod_loaded;
|
|
|
|
}
|
|
|
|
|
2015-06-26 10:57:15 -05: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)
|
|
|
|
{
|
|
|
|
int total_mod_loaded = 0;
|
2017-12-11 18:07:54 -05:00
|
|
|
struct module_vector alpha_module_list;
|
2015-06-26 10:57:15 -05:00
|
|
|
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
if (!alpha_module_list_create(&alpha_module_list)) {
|
|
|
|
int idx;
|
2015-06-26 10:57:15 -05:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
for (idx = 0; idx < AST_VECTOR_SIZE(&alpha_module_list); idx++) {
|
|
|
|
struct ast_module *cur = AST_VECTOR_GET(&alpha_module_list, idx);
|
|
|
|
|
|
|
|
total_mod_loaded += modentry(cur->resource, cur->info->description, cur->usecount,
|
|
|
|
cur->flags.running? "Running" : "Not Running", like, cur->info->support_level, data);
|
|
|
|
}
|
2015-06-26 10:57:15 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2017-12-11 18:07:54 -05:00
|
|
|
AST_VECTOR_FREE(&alpha_module_list);
|
2015-06-26 10:57:15 -05:00
|
|
|
|
|
|
|
return total_mod_loaded;
|
|
|
|
}
|
|
|
|
|
2015-07-13 10:54:51 -05: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)
|
|
|
|
{
|
|
|
|
int conditions_met = 0;
|
2017-12-11 18:07:54 -05:00
|
|
|
struct module_vector alpha_module_list;
|
2015-07-13 10:54:51 -05:00
|
|
|
|
|
|
|
AST_DLLIST_LOCK(&module_list);
|
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
if (!alpha_module_list_create(&alpha_module_list)) {
|
|
|
|
int idx;
|
2015-07-13 10:54:51 -05:00
|
|
|
|
2017-12-11 18:07:54 -05:00
|
|
|
for (idx = 0; idx < AST_VECTOR_SIZE(&alpha_module_list); idx++) {
|
|
|
|
struct ast_module *cur = AST_VECTOR_GET(&alpha_module_list, idx);
|
|
|
|
|
|
|
|
conditions_met += modentry(cur->resource, cur->info->description, cur->usecount,
|
|
|
|
cur->flags.running? "Running" : "Not Running", like, cur->info->support_level, data,
|
|
|
|
condition);
|
|
|
|
}
|
2015-07-13 10:54:51 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
AST_DLLIST_UNLOCK(&module_list);
|
2017-12-11 18:07:54 -05:00
|
|
|
AST_VECTOR_FREE(&alpha_module_list);
|
2015-07-13 10:54:51 -05:00
|
|
|
|
|
|
|
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 03:16:59 -04: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;
|
|
|
|
}
|
|
|
|
|
2017-12-29 19:24:02 -05:00
|
|
|
struct ast_module *__ast_module_running_ref(struct ast_module *mod,
|
|
|
|
const char *file, int line, const char *func)
|
|
|
|
{
|
|
|
|
if (!mod || !mod->flags.running) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return __ast_module_ref(mod, file, line, func);
|
|
|
|
}
|
|
|
|
|
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 03:16:59 -04: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];
|
|
|
|
}
|