When I start CLI, the prompt will appear normal but soon turns into some sort of unicode looking character stream. Inputs are also displayed as unicode and do not execute. Only Ctrl-c seems to work, and only on one of two computers. Here is an example:
In fact, I combined it with a kernel update and rebooted the entire machine.
Initially after I start CLI the display and prompt will be:
Only once there is some input or output will the prompt change. A lower case “c” gave me this:
A little later, once I have some output, it looks like this:
I have been accessing the machine using SSH. I would need to hook a monitor up to it to do as you suggest. I have been considering doing so. I have logged in with SSH from two different machines but both have been running Arch Linux (as is ZSPD).
I have the same problem, i’m running asterisk 13 LTS on arch.
Tried connecting directly on the linux console (keyboard+monitor instead of ssh) but I get the same result. As FixedWing reports, i can’t find much info around on that issue, tried nocolor but it doens’t help.
Just as a sidenote, i can enter 1 command on the asterisk cli if I connect to it directly without using the bash prompt with:
ssh myasteriskserver asterisk -rvvv
Then I can enter a single command and it will be executed. All subsequent commands will fail because a garbage character seems to be inserted at some point.
I am sorry that you are having this issue but also pleased to hear that I am not alone.
So, the common denominator appears to be Arch Linux. But I searched their forum earlier and didn’t see anything.
FYI, I am currently using linux-grsec 4.6.4.201607242014-1 on i686 architecture. I’ve updated the kernel a few times since this has happened. I’ve also updated Asterisk once.
It does make sense that it must be some program in the Arch install collection as it literally happened while the program was running. Before that, no problem whatsoever.
I’m using Linux alarm 3.14.65-16-ARCH on arm. i’m kinda glad to know it isn’t due to the arm environment…
You say it happened after a kernel update? Did you have to rebuild asterisk or just did it happen just after rebooting?
I tried to play with the locale/language/input environment parameters but same results…
I’m pretty sure i had it working correctly last month, I’ll try to find an old image.
Probably not a kernel update, that’s something that is different between the two of us, but probably the update of some other component. It literally happened one day when CLI had been running for a while. I went to bed and it was fine. I woke up in the morning and it was not fine. Unfortunately, by the time I’d thought about it enough to conclude that it was some component that had been upgraded, it was too late for me to figure out which component (assuming I’m even right, which I could easily not be).
Well i got an old image (± 1 month old), rebuild asterisk 13 lts, and the cli is just fine. I’ll try to make small updates and see which one breaks it…
Well if the bug comes from a single package, it’s one of these… I ran an update on a batch, didn’t really expect any of them to be the culprit (except systemd maybe…) But after i ran the update, without even rebooting or restarting asterisk, the bug appears…
Right on target
I reverted back to an old image and updated everything but libedit, and the cli is fine.
Just for the sake of completeness:
Works: libedit 20150325_3.1-2
Glitches: libedit-20160618_3.1-1
Not sure if the bug is in asterisk or libedit, but libedit might stay out of date for a little while on my servers
Thanks both for your help
I’m having the same issue with alarm. Is there an easy way to fix this problem? Which version of Asterisk does the problem first appear in? Or is the problem just with libedit? Is there a way i can rollback libedit on alarm?
downgrade libedit to the version described in Vincent’s post of July 27th: get the tar.xz from somewhere (maybe your package cache?: /var/cache/pacman/pkg/), invoke pacman -U on the package file, that should downgrade it. CLI should be working again after restarting asterisk. You yet have to be careful that on any system update you do from then on (pacman -Syu) to add --ignore libedit otherwise pacman will update your libedit back to the latest version!
my solution was yet different as I did not want to downgrade the system libedit (is used by other packages too and I am not sure about security fixes): as I build asterisk myself anyway, I added --without-libedit to its configure -line. This will force asterisk to build & use its own internal version of libedit, and not the one found in the system. That way, asterisk is independent of any updates to the Arch version of the lib.
I love this solution! I will do this the next time I build Asterisk. Thank you.
But meanwhile, there must be something about the configuration of libedit within Arch which is causing these problems. That would be the final solution. Anyone have any idea what it might be?
