Skip to main content

\reload"not working"""

Posted by owenc on Wed, 02/10/2010

We just moved from a test box using the CentOS install CD to a production box using our own OS and the newest version of asterisk. Everything is generally working other than we can no longer HUP asterisk from the GUI.

The little "Restart PBX" link comes up and if you click on it it goes away but nothing actually happens.

HUPing asterisk from the command line works just fine.

Looking into it, it appears that Thirdlane issues a "reload" command to cause this to happen. "reload" isn't accepted by asterisk (even logging in and issuing it manually). A little googling suggests that "reload" was depreciated in 1.4? Perhaps it was removed in a recent update?

Changing that command to "module reload" seems to get the desired effect.

Chris


Submitted by eeman on Wed, 02/10/2010 Permalink

more info including version of asterisk, if you installed 'make config' in order to start asterisk with the safe_asterisk script

reload works as recent as the most recent 1.6.1.x branch. restart pbx is not issuing a reload, its issuing a 'restart now'. HOWEVER, the pbx manager portal must be able to communicate over the AMI.

Submitted by owenc on Wed, 02/10/2010 Permalink

I'm using 1.6.2.2 and we are using the safe_asterisk script. We installed the safe_asterisk stuff mainly manually but that is all working fine.

I've confirmed that what the pbx manager portal sends to asterisk when you hit the "reload" button is the command: reload

That definitely doesn't work. I get the following:

Connected to Asterisk 1.6.2.2 currently running on voice (pid = 5968)
Verbosity is at least 3
voice*CLI> reload
No such command 'reload' (type 'core show help reload' for other possible commands)

We changed 'reload' to 'module reload' and now it works as expected.

Submitted by owenc on Fri, 02/12/2010 Permalink

I've confirmed this issue was caused by using 1.6.2.2. Not sure if "reload" is gone for good or if this is just a bug but since it has been deprecated since 1.4 some time it may indeed be going away.

Submitted by eeman on Fri, 02/12/2010 Permalink

i just found some disturbing dtmf bugs in the last several releases of all branches. You may consider sticking to 1.6.1.??? that was released around the same time as 1.4.26.2

anything newer than that seems to have an issue. I had to go back to 1.6.0branch because my dtmf wasnt getting relayed at all.

Submitted by eeman on Mon, 05/03/2010 Permalink

ok i have an answer i think you're going to like.. in 1.6.2.x theres now a cli_aliases.conf file.

it lets you bind aliases so old commands will work for you. I added the 3 restart aliases in the 14 template to the 'friendly' template so that reload and restart work. you'll find the config file in the sample configs directory in the source tree.

Submitted by eeman on Mon, 05/03/2010 Permalink

no, changing it in thirdlane would then break thousands of customers running 1.4.x, 1.6.0.x, and 1.6.1.x
and adding 'browser' detection code every time you need to reload will just slow the damn interface down more. this alias method is simple and instant relief.

1.6 branches are so horribly broken I can only think of 1 or 2 patch releases that don't have _something_ broken that you can't live without. You need to run bleeding edge release branches just to deal with the 'running out of udp socket' bug that will effectively DoS yourself. The most recent DTMF fixes appear to have a unforseen side-effect that now drops digits as before there were duplicates. So you now have to choose between dtmf issues or no available udp sockets every 1000 or so calls.

once we start working on 1.8 support we'll end up abandoning any 1.6 branches because theyre just too unstable and too many different command structures every few months