VoIP.infoThe independent guide to business communications.
VoIP.info Guide

Asterisk stop and restart evidence: now, gracefully, when convenient, Shutdown and FullyBooted

Plan an Asterisk stop or restart without confusing command acceptance, call admission, channel drain, process exit, initialization completion, module readiness and ordinary-call restoration.

Reviewed 2026-10-30Current official Asterisk stop-and-restart, running-process, FullyBooted, Shutdown, CoreStatus, process-directory, module-loading, logging, debug-collection and Reload documentation was reviewed October 30, 2026; installed branch, packaging, service manager, executable, process, control socket, PID file, active channels, admission path, shutdown request, module state, dependency readiness, logger output, traffic result, rollback and support response remain deployment-specific; no Asterisk host, FreePBX system, service manager, binary, process, socket, PID file, channel, call, module, event, log, restart, shutdown, readiness result, rollback or support case was inspected or testedAdvancedDocumentation based · not lab tested

Define the change and the service owner first

Record node, operating system, exact Asterisk branch and build, package or source provenance, service manager, wrapper, executable, process ID, control socket, start time, active channels, queues, bridges, trunks, maintenance owner, rollback and synchronized window. Establish whether the requested action is a core reload, module reload, service restart, process stop, host reboot or package change.

A CLI command, service-manager command and wrapper script can have different owners and restart policies. A retained PID file, control socket, console connection or green service state is not proof that the intended process, modules, endpoints and call paths are ready.

Choose now, gracefully or when convenient deliberately

Asterisk documents that core stop now and core restart now act immediately and end calls in progress. The graceful variants prevent new calls from starting while allowing current calls to finish before stop or restart. The when-convenient variants wait for no calls but do not prevent new calls from entering, so a busy system may continue waiting.

Record the exact command, issuer, approval, active-channel snapshot, admission behavior and abort threshold. Do not describe one mode as drain-safe without confirming the traffic and application paths that can still create channels.

Separate acceptance, drain, exit and restart

core abort shutdown applies to a previously initiated graceful or when-convenient stop or restart. Preserve command acceptance, pending state, new-channel observations, active-channel count, channel outcomes, AMI Shutdown event, process exit, service-manager transition and replacement PID as separate timestamps.

The AMI Shutdown event distinguishes cleanly versus uncleanly proceeding shutdown and whether a restart will occur. It does not identify every call outcome, the initiating owner, later process health or restoration.

Treat process startup and FullyBooted as bounded evidence

Asterisk documents FullyBooted as the AMI event raised after initialization procedures finish, with uptime and last-reload fields. Pair it with the expected executable, new PID, start time, service state, module inventory, configuration acceptance, endpoint or trunk state and targeted logs.

A new PID, asterisk.ctl, console banner, AMI connection or FullyBooted event answers a bounded readiness question. None alone proves every module is running, every external dependency is reachable, every registration recovered or an ordinary inbound and outbound call works.

Keep reload, restart and module recovery distinct

A reload can be accepted, queued, rejected, unsupported or already in progress without replacing the process. A restart replaces process state and can change module load order, volatile channels, caches and registrations. Module load troubleshooting also distinguishes loaded from running and uses startup logs to locate configuration or parse failures.

Preserve the requested action, AMI Reload status, module state before and after, configuration source, process identity and observed capability. Do not upgrade from reload to restart merely because a command returned little output.

Bound impact, preserve evidence and prove restoration

Before acting, define call-impact notice, last-admitted-call point, maximum drain time, abort or escalation condition, log-retention plan, rollback and independent access. Capture narrow startup and shutdown logs with timestamps, then restore normal debug levels and retain restricted originals separately from reviewed excerpts.

Verify the intended process and modules, endpoint or trunk recovery and the same bounded inbound and outbound ordinary-call cases used for acceptance. Command success, clean process exit, FullyBooted, quiet logs or a temporary traffic lull remains separate from verified service restoration.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Current Asterisk CLI, PJSIP troubleshooting, call-identifier and console-verbosity documentation reviewed September 30, 2026; no host, CLI, module, object, channel or call tested

Asterisk CLI: inspect the running system

Establish the exact running instance, loaded modules, PJSIP object graph and live call state before using a command that changes service.

Read guide →
Guide · Asterisk 22 LTS and current Asterisk configuration, CLI, dialplan, module-loader, PJSIP transport and restart documentation reviewed October 5, 2026; exact packaged builds, managed platforms and installed modules require runtime verification

Asterisk configuration lifecycle: source, reload, restart and proof

Trace one change from its supported configuration owner through generated input, loaded runtime state, activation scope, call evidence and rollback.

Read guide →
Guide · Asterisk branch-23-generated CoreStatus and CoreSettings references, branch-22-generated references for the same actions, and official AMI syntax, v2 and permission documentation reviewed October 16, 2026; installed branch and maintenance release, server identity, manager transport, account, ACL, read and write classes, action availability, returned fields, clock, restart and reload history, configured limits, runtime load, channels and downstream collector behavior remain deployment specific; no PBX, manager configuration, account, credential, socket, session, request, response, status value, setting, process, channel, packet, media stream or live call was inspected or tested

Asterisk AMI CoreStatus and CoreSettings: separate status from settings

Use the two core-query actions as correlated, node-specific evidence without turning a successful response into proof of call health, configuration ownership or capacity.

Read guide →
Guide · Current Asterisk 23 ARI Asterisk API and REST data models plus the Asterisk module-loader configuration guide reviewed October 10, 2026; no Asterisk host, ARI service, module directory, modules.conf, module binary, dependency, live channel, reload, load, unload, restart or call was inspected or tested

Asterisk ARI system and module operations

Identify the exact Asterisk instance, inventory its running modules and place explicit safety gates around load, reload and unload actions.

Read guide →
Guide · Current Asterisk logging, runtime command, logger.conf, debug-collection, call-identifier and console-verbosity documentation reviewed September 30, 2026; no process, logger, trace, storage path or call tested

Asterisk logging without permanent debug overload

Map configured destinations, console levels, call identifiers and a bounded protocol trace without leaving sensitive debug collection active.

Read guide →
Guide · FreePBX 17 / Debian 12; module UI varies

FreePBX module administration and updates

Inventory module state, preview dependencies and signatures, change the smallest intended set, and prove reload and call behavior before closing the window.

Read guide →
Troubleshooting · Current official Asterisk stop-and-restart, running-process, FullyBooted, Shutdown, CoreStatus, process-directory, module-loading, logging, debug-collection and Reload documentation was reviewed October 30, 2026; installed branch, packaging, service manager, executable, process, control socket, PID file, active channels, admission path, shutdown request, module state, dependency readiness, logger output, traffic result, rollback and support response remain deployment-specific; no Asterisk host, FreePBX system, service manager, binary, process, socket, PID file, channel, call, module, event, log, restart, shutdown, readiness result, rollback or support case was inspected or tested

Asterisk graceful stop or restart keeps waiting, aborts or leaves readiness unclear

Find the first gap across command mode, channel admission, drain state, shutdown event, process replacement, module initialization, FullyBooted and ordinary-call restoration.

Read guide →