Asterisk AMI module checks, load, reload and refresh

Name the exact module and expected capability

Start with the Asterisk branch and build, installed package, module directory, exact shared-object name and the feature it should register: a channel driver, dialplan application or function, resource, codec, file format, CDR, CEL or bridge driver. module show inventories loaded modules and use counts, but a row does not establish that the desired configuration or runtime object exists.

Preserve the package source and version separately. The generated ModuleCheck reference documents an empty Version response field, so that action must not be used as version evidence.

Use ModuleCheck only for loaded state

ModuleCheck tests whether a module is loaded and returns success or failure. Its Module argument omits the file extension, which differs from module-target syntax used by ModuleLoad. Retain the raw response and ActionID, and compare it with a bounded CLI inventory when diagnosis requires a second surface.

Loaded state is one observation. It does not establish that an application, function, AMI action, endpoint, transport or other feature registered successfully.

Choose load, unload, reload or refresh deliberately

ModuleLoad accepts load, unload, reload and refresh. A module target includes the .so suffix; a subsystem identifier can be supplied for reload, and the generated reference says subsystem identifiers can only be reloaded. refresh completely unloads and loads the module.

Treat unload and refresh as service-affecting changes. Do not force an unload from automation: the official CLI reference warns that forced unload options can cause a crash.

Bound recursive and all-module scope

For refresh, the documented Recursive argument attempts to unload and load dependent modules recursively. Inventory dependencies and active use before considering it, and preserve a tested recovery path. A successful request does not describe every dependent registration or call impact.

A ModuleLoad reload without a module reloads all modules. The separate Reload action sends a reload event and optionally names a module. Prefer the narrowest supported target and correlate its response with module-specific logs.

Keep runtime action separate from startup policy

modules.conf controls durable module-loader policy through autoload, preload, require, preload-require, noload and load. A module loaded during runtime may disappear at restart; a noload or missing load rule can be the durable explanation. A required module that cannot load causes Asterisk to exit with status 2.

Review the actual configuration owner before editing the file. Package upgrades and administration platforms may change the installed module set or regenerate policy.

Verify registration, configuration and behavior separately

After a bounded action, confirm loaded state, the expected registered application, function, driver or manager action, the target module configuration and one intended runtime object. Then run an authorized acceptance case and preserve signaling and media evidence appropriate to it. These checkpoints locate the first divergence without treating a generic success response as end-to-end proof.

Restrict AMI permissions and network reachability, redact credentials and schedule disruptive changes. No PBX, module, package, manager session, configuration file, channel, packet, media stream or live call was inspected or tested for this guide.

Verify action registration after module state

The AMI command-inventory guide continues from a loaded module to the administrator registry and the commands visible to one manager user.

Bind module control to branch, build and registration evidence

ModuleCheck and ModuleLoad do not prove source inclusion, dependency resolution, build selection or capability registration. Use the version/build diagnostic to find the first missing boundary.