Sparse Logfiles

jcolp · October 29, 2025, 5:36pm

It’s probably due to this:

github.com/asterisk/asterisk

[bug]: /var/log/asterisk/full lacking details

opened 01:47PM - 22 Sep 25 UTC

closed 01:48PM - 23 Sep 25 UTC

Smatteo94

bug triage support-level-core

### Severity Major ### Versions 20.15.2 - 22.5.3 ### Components/Modules /va…r/log/asterisk ### Operating Environment Debian 12.12 ### Frequency of Occurrence Constant ### Issue Description Problem Description Asterisk log files (/var/log/asterisk/full) are practically empty or showing only few KB in size, containing no call details or events, despite logging settings being properly configured. Affected Asterisk Versions Asterisk 20.15.2-1 (problematic) Asterisk 22.5.2-1 (problematic) Working Asterisk Versions (Workaround) Asterisk 20.15.0-1 (downgrade resolves the issue) Asterisk 22.5.0-1 (downgrade resolves the issue) System Environment Operating System: Debian 12.12 FreePBX: Version 17 Configuration: Multiple production machines Comparison: FreePBX 15 does not exhibit this problem Observed Symptoms Asterisk Console: Correctly displays all events and information Log Files: /var/log/asterisk/full and rotated files (full.x) have only few KB in size Log Content: Complete absence of events and call details Configuration: Log Settings properly configured (all enabled/on) Problem Timeline Start: Approximately one week before the report (mid-September) Previous State: Everything was working correctly Persistence: Problem persists even after Framework downgrade Tests and Identified Workaround Failed Test: FreePBX Framework downgrade (problem persists) Successful Test: Asterisk downgrade to previous versions Verification: core show settings command correctly shows 3 verbosity levels after downgrade Result: Complete restoration of logging functionality Impact Criticality: High (production systems) Scope: Complete loss of call traceability Monitoring: Inability to debug and analyze phone traffic Root Cause Analysis The problem appears to be a regression introduced in the latest Asterisk versions (20.15.2-1 and 22.5.2-1) that compromises the file logging mechanism while keeping console output functional. Requested Action Investigation and correction of the bug in Asterisk versions 20.15.2-1 and 22.5.2-1 to restore proper file logging functionality. Reproduction Steps Install Asterisk 20.15.2-1 or 22.5.2-1 on Debian 12.12 Configure FreePBX 17 with standard logging settings Generate call traffic Observe that console shows events but /var/log/asterisk/full remains nearly empty Expected Behavior Log files should contain detailed information about calls, events, and system activities as configured in Log Settings. Actual Behavior Log files contain minimal or no information despite proper configuration and console output working correctly. ### Relevant log output ```shell ``` ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

github.com/asterisk/asterisk

[bug]: safe_asterisk without TTY doesn't log to file

opened 02:05PM - 17 Oct 25 UTC

closed 04:27PM - 22 Oct 25 UTC

whitmangroup220-cloud

bug support-level-core

### Severity Major ### Versions 22.1, 22.2, 22.3, 22.4, 22.5, 22.6 ### Compo…nents/Modules Logger ### Operating Environment Rocky Linux ### Frequency of Occurrence Constant ### Issue Description Logger is no longer recording call detail to messages or full log even with verbose and debug set. V 22.6 did not have this problem v20.16 exhibits this problem where earlier versions did not. In logger.conf ;messages => notice,warning,error messages => notice,warning,error,debug,verbose ; full => notice,warning,error,debug,verbose,dtmf,fax ;full => notice,warning,error,verbose Refuses to log VERBOSE entries that appear in console but not written to log like this entry: [2025-10-15 11:03:49] VERBOSE[45989][C-0000009e] pbx.c: Executing [1@trinity_call2017:1] System("PJSIP/zsiptrunk-0000013d", "/var/lib/asterisk/agi-bin/log_aster.pl "Trinity_Dialup User selected option 1"") in new stack No Verbose entries written to log ### Relevant log output ```shell ``` ### Asterisk Issue Guidelines - [x] Yes, I have read the Asterisk Issue Guidelines

And had to do with safe_asterisk. We have subsequently done a pull request to restore things:

Which will be in the next set of releases, with release candidates tentatively happening this week and full releases next week (from an Asterisk perspective).