Asterisk AMI module is loaded but missing, not running or wrong

Freeze one module, node and symptom

Record the responding node, installed branch, exact expected module and filename, feature that is missing, package or build inventory, modules directory, modules.conf policy, dependency state, manager identity and symptom time. Preserve module show like, the original AMI request and nearby startup or reload logs.

Classify the first divergence: file not built or installed; wrong node; ModuleCheck name includes the wrong form; manager action rejected; noload or explicit-load policy excludes it; dependency unavailable; load Failure or Decline; library loaded but Not Running; configuration rejected; refresh blocked by a dependant; event hidden by permissions; or later feature state is wrong.

Separate installed, loaded, running and configured

Confirm the binary exists in the active modules directory and belongs to the installed build before interpreting AMI. Then check whether Asterisk loaded it, whether module show reports Running and whether configuration parsing completed without errors.

Do not repeatedly load a module whose configuration is invalid or whose dependency is absent. Repair the first failed boundary through the package, build or configuration owner and retain the exact error.

Match the action to the intended lifecycle

Use load only for an unloaded module, reload only when the module or subsystem supports reloading, unload only after dependency and active-use review, and refresh only when a complete unload-and-load cycle is justified. Recursive refresh can affect dependants and requires an explicit wider change window.

Never omit the module from a reload request as a shortcut: the documented result is a broad reload. Do not substitute a CLI force or hard unload; official module-loader guidance warns those options can crash the process.

Correlate response, event and post-action state

Retain the unique ActionID, response, lifecycle events and timestamps, then repeat the narrow state query. A successful response without a visible event can be an event-permission or filter issue; an event without the expected capability can be a Running, configuration or dependency problem.

Interpret Load Status precisely: Success is loaded and configured, Failure is a failed load and Decline means not configured. A Reload event does not prove that every configuration object or downstream consumer changed.

Preserve FreePBX and startup ownership

On FreePBX or another generated platform, identify whether module administration, package management or generated configuration owns the persistent state. A direct runtime action can be overwritten by the next Apply Config, module update or restart and may bypass signature or compatibility controls.

Compare the intended startup policy with autoload, preload, require, noload and explicit load entries. A runtime fix is not complete until the supported owner will reproduce the state safely after restart.

Verify the first exported capability once

After the narrow correction, prove the module is loaded and Running, then verify one expected CLI command, API route, channel driver, resource or other exported capability. Stop at the first confirmed boundary; validate registrations, routes, calls and media separately if authorized.

Record before-and-after module state, configuration, events and capability. No PBX, module file, dependency, configuration, manager action, channel, packet, media stream or live call was inspected or tested.

Distinguish a removed recorder from a failed module load

The AMI Monitor diagnostic stops unsafe recovery attempts when the running branch no longer contains res_monitor.

Follow chan_dahdi into the driver layer

The AMI DAHDI diagnostic separates module visibility from kernel driver, configuration and hardware ownership.

Follow chan_dahdi into PRI and DAHDI evidence

The AMI PRI diagnostic keeps module registration distinct from span inventory, driver state and carrier service.

Do not try to load chan_sip on a branch that removed it

The missing SIPpeers diagnostic routes Asterisk 21 and later toward PJSIP migration evidence.

Correlate module events with restart identity

The restart diagnostic keeps the module file, process, configuration and startup window together.