After bringing FreePBX (official FreePBX Distro install) and CentOS current, clicking “Apply Config” causes asterisk to crash and restart.
FreePBX is on 10.13.66-18
Asterisk is running on 13.14.0
All FreePBX modules are up to date.
In the course of troubleshooting I tried on a server than is not currently up to date but recent.
FreePBX 10.13.66-17
Asterisk 13.13.1
The problem does not exist.
Ran a CentOS “yum - y update” which brought Asterisk to 13.14.0 but did not update any modules or FreePBX, and the problem began.
This appears that it could be a bug in Asterisk 13.14.0 or a change in how it responds to the reload that FreePBX is sending.
Also to note, a “core reload” from the asterisk CLI works fine and does not result in a crash.
A “fwconsole reload” from the CentOS CLI does result in a crash.
Reviewing asterisk CLI Verbose and Debug output with both manager and agi debug on, nothing jumps out at me. Just throws a segmentation fault and asterisk dies.
I have been able to reproduce this on two systems at this time.
–update–
Commenting out #include http_additional.conf and #include http_custom.conf in /etc/asterisk/http.conf appear to resolve the issue.
I’m doing a bit more research on this now. I’ll update again if I learn more.
Sadly no, that doesn’t fix it. It just slightly delays the crash. Running ‘core reload’ a couple of times from the console will still crash it.
I’m working with the Asterisk developers now, trying to nail down the actual problem. For the moment, this has been pulled, and you should go back to Asterisk 13.13.1
You can do this with yum downgrade asterisk13-* and then asterisk -rx 'core restart when convenient ' which will wait for no calls to be in progress and then restart with the older version.
We are seeing this also on the one system we have updated to FreePBX 10 release 18. We also see a core reload works fine. Just the apply from FreePBX crashes.
kernel: asterisk[58428]: segfault at 0 ip 00007f9fd37823f6 sp 00007f9ee4599f38 error 4 in libc-2.12.so[7f9fd365a000+18a000]
What does the apply function do that is different from “core reload”?
Here at FreePBX Airways we take your comfort and convenience seriously. We understand that some passengers may not have appreciated our new, fully automatic, ‘rapid passenger eject’ feature of the latest Asterisk version, which helped shorten your debarkation time, call lengths, and save on billing charges by ensuring calls were terminated quickly.
Unfortunately, passengers were being ejected while we were still at cruising altitude, which caused them some discomfort. As such, we have removed that feature, and we’re currently in the process of publishing new asterisk RPMs with that functionality removed.
We hope you enjoy your flight, and remember to keep your seatbelt fastened low and tight while seated. Our cabin crew will be through shortly, serving light refreshments.
Once again, thanks for flying FreePBX Airways, with the motto ‘FreePBX Airways: Who made this motto anyway?’.
In all seriousness, however, I’m really sorry about this. This was actually my fault, in that I assigned the new Asterisk builds to QA, and then three hours later, looked at the status (which was STILL ‘QA’) and read it as ‘QA Pass’, and moved them into production.
The new Asterisk builds are being sent out to the mirror servers now, and if you were one of the unlucky ones that did get the briefly available broken version, you will be able to update shortly.
Here is where we shine. Asterisk breaks something and we hot patch it before Digium even has a release with the fix so Asterisk 13.14 is patched with the fix while the same version from Digium is still broke.
this is not a bug, need to edit http_additional.conf is Advanced Settings - Asterisk Builtin mini-HTTP server
I fixed the field
Enable TLS for the mini-HTTP Server YES -> NO
HTTPS Bind Address [::] -> 0.0.0.0
