Search the Asterisk Blog

Asterisk 16 has a new module loader

By Richard Mudgett

One of the improvements to Asterisk 16 is the module loader. The module loader now enforces inter-module dependencies and complains of modules that fail to initialize. The module loader ensures that a module is not started before other modules it depends upon. Therefore, if module B depends upon module A and module A either does not exist or fails to start then the module loader blocks module B from starting.

One of the goals of the new module loader was to eliminate the need for the ‘preload’ option in modules.conf. Therefore, using the ‘preload’ option is no longer necessary. In fact there is no good reason to use ‘preload’ anymore. Previous versions of Asterisk required you to use ‘preload’ for the realtime drivers if you wanted to use realtime configuration. The realtime drivers needed to load before initializing the Asterisk core parts that use configuration. Now the parts of the Asterisk core like CDR, CEL, and features are setup as built-in modules which get “loaded” using the same module loading system as loadable modules like res_musiconhold.so. The realtime drivers simply have a more urgent loading priority than the built-in modules.

The new module loader is more strict about loading modules. Thus some things you were able to get away with in earlier versions generate error messages at startup.  To demonstrate the kinds of errors reported by the module loader you can experiment with this test environment. Setup an environment using the following commands:

  1. ./configure –with-jansson-bundled –with-pjproject-bundled
  2. make && sudo make install
  3. sudo rm /usr/lib/asterisk/modules/res_pjproject.so
  4. sudo cp configs/samples/modules.conf.sample /etc/asterisk/modules.conf
  5. sudo cp configs/samples/logger.conf.sample /etc/asterisk/logger.conf
  6. sudo asterisk -cg

The captured console output is at the end of the blog for reference.

Strategy for fixing loading issues.

A simple strategy for fixing loading issues is: Fix the errors you can first. Doing this reduces the number of errors and may fix other errors you currently do not understand.

The error with chan_pjsip.so loading looks more serious than the others. However, if you do not know that chan_pjsip.so depends upon res_pjsip.so and that res_pjsip.so defines that symbol you would not have much of a clue on how to fix the problem with chan_pjsip. If you start fixing the other errors that you can you may wind up fixing the problem with chan_pjsip.so in the process.

Most of the errors at the beginning of the console output are complaining of missing configuration files. We can easily fix those by supplying configuration files. One way is to install the sample configuration files with: sudo make samples. Providing configuration files not only reduces the messages about missing configuration files it reduces the number of messages about modules declining to load. Modules can and some do fail to initialize if a configuration file is missing. Another way to fix missing configuration file errors is to not load the module if you do not need the functionality it provides.

When you get to the module loading error with func_pjsip_contact.so you see that it is complaining that the res_pjsip module it depends upon is missing. With the command line interface (CLI) command “module show” or the related “module show like <substring>” you can see what modules are actually in memory. In this case res_pjsip.so is not in memory, the module exists in the /usr/lib/asterisk/modules directory, and there is another error message saying res_pjsip.so is missing the res_pjproject module it depends upon. Examining the res_pjproject module in turn you find that the res_pjproject.so module file does not exist. Fixing the reason why the res_pjproject.so module is missing then winds up fixing the problem with chan_pjsip.so and just about all the other res_pjsip module loading issues at the same time. The reason res_pjproject.so is missing in this case is because we intentionally deleted the file to demonstrate.  Another reason it could be missing is that there was an error building the module.

Wrapup

A benefit of the new module loader is that it can help identify modules you do not need. When a module declines to load it is in memory and not initialized. If you do not need the module you can simply use the ‘noload’ option in modules.conf. Conversely it helps you determine which modules you need to load if a dependency is missing for a module you want to use.

Reference

 

No Comments Yet

Get the conversation started!

Add to the Discussion

Your email address will not be published. Required fields are marked *

About the Author

Richard Mudgett

Richard Mudgett is a Senior Software Developer at Digium. While a prolific developer and contributor to Asterisk, he's elusive and can be difficult to spot outside of his native #asterisk-dev environs. We were impressed we got him to write a blog post.

See All of Richard's Articles

More From
The Digium Blog

  • No items