Asterisk CLI lost colors over SSH after config changes

[rezuan_cse]

Asterisk CLI lost colors over SSH after config changes

Version: Asterisk 13.23.1 on CentOS 7

After some configuration changes, the CLI console (asterisk -r) stopped showing highlighted text over SSH.

I have two identical servers. One works fine (see screenshot 1), the other lost colors (see screenshot 2).

Already verified on both servers:

• TERM=xterm-256color, tput colors = 256

• nocolor commented out in asterisk.conf

• console = yes in [options]

  Screenshot1

  

Screenshot2:

**Question:** What controls full ANSI color output in the interactive asterisk -r session?

What I’m trying to resolve is how to make the CLI output in Screenshot 2 display the same colors as the CLI output in screenshot 1.

[cable]

Probably a Linux setting. Try:

tput init

[rezuan_cse]

@cable

tput init

Tried but the output is still remain same.

[cable]

Try:

tput reset

[rezuan_cse]

I just tried it also, but no luck. I’m thinking about rebuild the binary. Will update here once resolved.

[kingasterisk]

In the interactive CLI of Asterisk, ANSI color output depends on terminal capabilities and the nocolor option in asterisk.conf. If nocolor is enabled or the terminal type ($TERM) does not support ANSI colors, the CLI will display plain text. Ensure nocolor is disabled and the SSH session uses a color-capable terminal like xterm or xterm-256color.

[rezuan_cse]

I’m using termius which is already color-capable. nocolor is set disable but the CLI output is remain same.

[rezuan_cse]

[Solved] Missing CLI Colors on CentOS/RHEL when using Systemd

The Problem I was struggling with an issue where my Asterisk CLI output was completely colorless (no green/cyan/red highlights) on my CentOS server when viewed via Termius. This made reading SIP traces and call flows very difficult. Even though I copied asterisk.conf from a working server and set COLOR=yes, the output remained plain white/gray.

The Root Cause The issue was twofold:

1. Environment Stripping: The default CentOS init.d scripts and standard binary execution often fail to pass the correct TERM variable to the Asterisk process.

2. The Wrapper Factor: Starting the binary directly via /usr/sbin/asterisk behaves differently than the safe_asterisk wrapper, which handles console initialization more effectively for modern SSH clients.

The Solution I resolved this by moving away from legacy startup methods and creating a modern Systemd unit file. This ensures that the environment is explicitly set before the process starts.

Steps to Resolve:

1. Stop any existing Asterisk processes: pkill -9 asterisk

2. Create a modern Systemd service file: vi /etc/systemd/system/asterisk.service

3. Paste the following configuration: (Note: Using Type=forking is critical when calling safe_asterisk.)

Ini, TOML

[Unit]
Description=Asterisk PBX with Safe Wrapper
After=network.target

[Service]
Type=forking
User=root
Group=root
# Force the terminal type for ANSI color support
Environment=TERM=xterm-256color
# Use the safe_asterisk wrapper for stability and color initialization
ExecStart=/usr/sbin/safe_asterisk
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

4. Reload the system and start the service:

   Bash

   systemctl daemon-reload
   systemctl enable asterisk
   systemctl start asterisk
   
   

Result: By explicitly setting Environment=TERM=xterm-256color and calling the wrapper, the CLI now displays full ANSI colors immediately upon entering asterisk -rvvv.

Kindly note that, I have done it by the help of Google Gemini.