FreePBX 15 reload takes a long time on some non-distro platforms


Since you said it’s not (wasn’t) installed I am questioning whether I installed that package at one point unnecessarily.


New Distro installed on DigitalOcean from 2002 (Feb.) ISO, no modifications from stock install, GUI reloads take 4 seconds. That’s not great, but it’s not what you are describing.

yum update to get it to current (Distro 2008) and fwconsole ma upgradeall to get the modules current,

still seeing 4 second reload times in the GUI.

I’m not writing this to say the problem doesn’t exist, just that those of you experiencing it, need to give more details on how to reproduce it.


More messing around…

# time fwconsole util signaturecheck

real	0m2.914s
user	0m1.627s
sys	0m0.715s

I deleted the directory /home/asterisk/.gnupg to force an online refresh and ran the same command. Time was just a little longer…

# time fwconsole util signaturecheck

real	0m3.601s
user	0m1.642s
sys	0m0.766s

(Jared Busch) #24

My live PBX, a distro system on Vultr $5 instance. I think it was FreePBX 13 upgraded over time to current.
The console takes ~11 seconds on average to reload.

Clicking the button in the GUI takes ~20 seconds.


How long does fwconsole util signaturecheck take? Is it possible the delay you are seeing is not entirely related to the signature system?

(Jared Busch) #26

Highly possible. Like I said, I’ve done zero troubleshooting.

But I have noticed this difference on every FreePBX 15 system I have touched. SOme more than others.


Got a Raspberry Pi laying around?:


root@FreePBX:~# time fwconsole reload
Reload Started
Reload Complete

real 0m3.503s
user 0m2.534s
sys 0m0.944s
root@FreePBX:~# time fwconsole reload
Reload Started
Reload Complete

real 0m3.519s
user 0m2.600s
sys 0m0.924s
root@FreePBX:~# time fwconsole reload
Reload Started
Reload Complete

real 0m3.530s
user 0m2.676s
sys 0m0.851s

GUI (Signature Checking Enabled): 48 seconds

GUI (Signature Checking Disabled): 3.5 seconds


Nope. Is it essentially Debian Buster on ARM? Would your configuration work on a Buster/ARM VM?

Since it was stated that the problem occurs on Distro x86_64 I would be even more interested in seeing it there, since that would be the best platform for reproducing and fixing the bug in Sangoma’s lab.


Probably, but not without some massaging of the installation script (mostly deletions of Raspberry Pi hardware and boot specific items). It’s not ARM specific. Others have reported altering for use on cloud installations.


We’ve just ended up disabling signature checks. They also did something to break signature checking on our 3rd party modules, so we were seeing big red warnings that needed dealing with. Speedier reloads were an added bonus.