Cli no color since version 18.9.0

in etc/asterisk/asterisk.conf i have this config

nocolor = no

on version 16.17 when i run asterisk -rvvv the console is colored
but on 18.9 everything is just black any tip would be appreciated.

I am using Asterisk version “16.16.1~dfsg-1+deb11u1”, and the only way to solve it (at least for me) was to accomplish the following:

  • Add the “nocolor=no” in the “/etc/asterisk/asterisk.conf” file.

As this did no help further despite a restart of my Asterisk platform, I have done the following:

  • Add “export TERM=xterm-256color” in the “/root/.bash_aliases” file (this file is called by “/root/.bashrc”.).

I rebooted the entire server, and then have fired the following command to get the Asterisk CLI prompt:

  • sudo -u asterisk asterisk -rvvvgc”.

These steps did help me under the Debian Bullseye platform to get a colourful CLI output :wink:

Unless sudo is invoked with the ‘’–login’ option, the user’s shell is not invoked as a ‘login shell’ (i.e. bash --login) and the user’s login-specific resource files (i.e. .bash_profile/.bashrc) will not be read.

Also, I think you will find that ‘-r’ ignores ‘-c’ since -r connects to an already executing instance of Asterisk.

Thank you for the feedback on this. Indeed the command syntax

  • sudo -u asterisk asterisk -rvvv ”.

works fine as well. I’m just figuring out, where I need to amend further any settings to get a coloured CLI output.

Here the contents of the “/lib/systemd/system/asterisk.service” file after the Asterisk installation:

[Unit]
Description=Asterisk PBX
Documentation=man:asterisk(8)
Wants=network-online.target
After=network-online.target

[Service]
Type=notify
ExecStart=/usr/sbin/asterisk -g -f -p -U asterisk
ExecReload=/usr/sbin/asterisk -rx 'core reload'
Restart=on-failure
RestartSec=1
WorkingDirectory=/var/lib/asterisk
[Install]
WantedBy=multi-user.target

Unless I’m mistaken, all “systemd” start-up and shutdown of processes are executed within a “root” context and amongst others, are also using the “$TERM” environment variable for their services.

@jcolp can i report an issue ?

Can you? You have the ability to. Is it a valid issue? I don’t know. I haven’t seen anyone else report such a thing, and haven’t experienced it personally.

https://issues.asterisk.org/jira/browse/ASTERISK-29902
opened a issue

I think this is just an issue requiring clarity.

Some command line options are appropriate for starting an Asterisk server (-C, -c, -f, -g, -h, -p, etc.) and some are appropriate for starting a console to an already running server (-C, -h, -n, -R, -r, -x, etc.) and some are appropriate for both.

Maybe a notice when a console is started with server options or a server is started with console options would be helpful.

i opened an issue with cli color did i miss understand need to start asterisk differently ?
in 16 everything is ok

I don’t think there is an issue. I think it would be helpful if notified when command line options are used inappropriately rather than silently ignored.

This has nothing to do with versions. It’s been this way forever AFAIK.

I have had this issue when performing a new, plain vanilla installation last week under Debian Bullseye, no upgrade whatsoever. This Linux distribution allowed the installation of Asterisk version “16.16.1~dfsg-1+deb11u1 ” with the OS included packages.

I tried several approaches as outlined in my posting above, and it seems that the coloured CLI is now working. Before, the CLI output was just uniformly displaying using white letters only.

Thus, not sure whether my observations are based on the package installation coming with this Linux distribution, or whether additional steps are really required.

For sure, after the bespoken Asterisk package installation, I had to review the config files and reapply the settings from my learnings of previous versions of Asterisk installations.

For now, the coloured CLI output is working, when performing an application restart within a terminal session or when rebooting the server.

Thank you Sean Bright

I_think_ you want to create a file named /etc/sysconfig/asterisk and put the following in it:

COLOR=yes

And then stop and start Asterisk.

I would say it was environment. The file /etc/init.d/asterisk talks a bit about the sysconfig overrides, but this is specific to RH/CentOS.

Thank you for the feedback on this.

I have checked the /etc/default/asterisk file under the Debian 11 Bullseye distribution. It contains lots of variables that can be pre-set and altered, however the variable COLOR does not exist that I can pre-set to the bespoken default value.

I installed Asterisk 19.2.0 on Debian 11.2.0.

The file /etc/default/asterisk contains a setting for terminal (aka console) color:

# If you DON'T want Asterisk to start up with terminal colors, comment
# this out.
COLOR=yes

The comment is incorrect.

/etc/init.d/asterisk shows:

        if test "x$COLOR" = "xno" ; then
                ASTARGS="$ASTARGS -n"
        fi

So the comment should read something like:

# If you DON'T want Asterisk to start up with terminal colors, set this
# variable to 'no'. Any other value will enable color.
COLOR=no

Personally, I’d rather fiddle with /etc/asterisk.conf than a distribution specific file.

(Actually, I abhor terminal colors – they make screencaps hard to parse :slight_smile: )

Looks like I have resolved the issue by creating an “override” file with the following contents:

[Service]
EnvironmentFile=-/etc/default/asterisk
Environment=TERM=xterm

Setting the TERM variable, did resolve the issue in getting the coloured CLI output back when firing a command on the Asterisk prompt after a server restart.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.