FreePBX Asterisk Logfile Settings: generated channels, runtime and retention

Prove the installed module and security boundary first

Inventory the installed Asterisk Logfiles module, its enabled and signed state, exact version and available update channel before relying on the Settings or Reports page. The reviewed FreePBX advisory addresses authenticated SQL injection in the Logfiles module and directs administrators to update to the latest release. Treat repository metadata and a visible page as discovery evidence, not proof that the running host contains the correction.

Keep the administrator interface restricted to trusted management paths, preserve a backup and change record, and update through supported Module Admin controls before expanding log access. Do not expose the web interface or grant broad administrator rights as a diagnostic shortcut.

Separate saved rows from generated logger configuration

Record the intended file or console channel and each selected level in Asterisk Logfile Settings. Then inspect the generated logger include owned by the module and compare its channel name and level list with the saved rows. A successful form submission or Apply Config banner does not prove that the expected generated line exists.

Preserve FreePBX ownership of generated files. A direct edit can temporarily make a file write while leaving the database, future generation and rollback inconsistent; use a supported custom include only when its ownership and precedence are documented for the installed system.

Prove the loaded logger channels and one attributable write

Use Asterisk logger show channels to inventory the runtime channels and core show settings to observe current debug and console verbosity. Keep persistent channel configuration separate from transient core set verbose, core set debug, protocol logger and dynamically added channel state. A file on disk can be old, while a loaded channel can point elsewhere or reject writes.

Generate one authorized, timestamped, non-emergency event that should emit at a selected level. Correlate the call or operation identifier, loaded channel, destination path, file modification time and new record. Do not infer healthy logging from a CLI message alone or from unrelated lines already present in the file.

Follow the write path through permissions, storage and time

If the configured channel is loaded but the destination stays empty, inspect the process identity, parent directory and file ownership, free bytes and inodes, read-only mounts, security controls and any file descriptor still referencing a rotated file. Keep application event generation, logger filtering and operating-system write failure as separate branches.

Record system and PBX timezone, clock synchronization and timestamp format before concluding that an event is missing. Search by a stable call or transaction identifier and bounded time window rather than publishing an unredacted full log.

Give rotation and retention one explicit owner

Asterisk exposes logger rotation and FreePBX generates logger policy, while operating-system logrotate can also rename, recreate and signal the service. Inventory every owner and the files each controls before changing frequency, count, compression or post-rotate reload behavior. Competing mechanisms can produce unexpected names, file descriptors and retention.

Sangoma’s retention note documents /etc/logrotate.d/asterisk and historical FreePBX Distro defaults as an operational example. Do not apply its seven-, thirty- or sixty-day values unchanged to a FreePBX 17 Debian 12 host. Derive retention from evidence needs, call volume, disk budget, privacy policy, backups and legal requirements, then prove rotation and continued writes on a non-production-equivalent path.

Keep queue logs, FreePBX logs and temporary debug distinct

The Asterisk queue log is a structured queue-event stream, ordinary Asterisk channels filter logger categories, and FreePBX application or security logs have different producers and controls. Verify the requested evidence source instead of enabling every category in full. CDR and CEL records are also separate lifecycle evidence, not substitutes for a missing logger channel.

For temporary debug, Asterisk documents narrow channel creation, explicit verbosity and protocol logging followed by cleanup. Disable the extra levels and protocol trace, remove the temporary destination, reload as required, verify normal logging and record the retained or securely deleted artifact. Redact credentials, tokens, phone numbers, public addresses and personal call content before sharing.

Use logs to explain a dashboard boundary, not replace it

When a dashboard provider fails, the focused diagnostic correlates module and collector errors in the same window. A log line is evidence for that component, not proof of every card or PBX outcome.