A recent change to app_voicemail made it such that the module now assumes that
all format modules are available while processing voicemail configuration.
However, when autoloading modules, it was possible that app_voicemail was
loaded before the format modules. Since format modules don't depend on
anything, set a module load priority on them to ensure that they get loaded
first when autoloading.
This version of the patch is specific to Asterisk 1.4 and 1.6.0. These versions
did not already support module load priority in the module API. This adds a
trivial version of this which is just a module flag to include it in a pass before
loading "everything".
Thanks to mmichelson for the review!
(closes issue #16412)
Reported by: jiddings
Tested by: russell
Review: https://reviewboard.asterisk.org/r/445/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@233782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@199022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully
initialized and must be initialized using "module load".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
against older Asterisk 1.4 headers will now load properly with just a warning
indicating that they are old and may cause problems.
(patch by paravoid)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
what build options were used. We agreed that we should remove this before
making a 1.4 release, and then we can put it back in. Then, we can take a
month or so to play around with it to get it how we want it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89325 65c4cc65-6c06-0410-ace0-fbb531ad65f3
all of the modules. "stop now" is considered a non-graceful shutdown and will
not go through this process.
(issue #9804, reported by chrisost, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
also, keep trying to dlclose() a module until it actually goes away, since it may have other modules it brought in when it was loaded (thanks PCadach for pointing this problem out to me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
