@billsimon Need to pick your brain on this. Just did a manual install on Ubuntu 18.04 / FreePBX v16 / PHP7.4. Everything is working fine with the system, no errors getting kicked out or any problems like that. However, doing an Apply Config from the GUI results in the GUI just hanging for upwards of five minutes. Watching things from the backend, everything reloads fine and quickly. Configs are generated correctly, Asterisk restarts but the GUI just hangs.
I did another box a few months back, Ubuntu 18.04 / FreePBX v15 / PHP7.2 and the same thing is happening. I figured once 16 came out and I could fully move to 7.4 that would hopefully solve it. But this new install with that setup is showing the same symptoms.
Not a single bit. Works fine the only delays I see are in the GUI and that seems to be more GUI facing that anything. All the changes are already accepted and being used before the GUI says the reload is done.
Check dns. Make sure you can ping the hostname of the machine. “hostname” at the command line will return the system host name. Can you ping that? If not, add an entry to /etc/hosts.
I haven’t seen slow GUI reloads in Debian. I haven’t tried Ubuntu, but I would expect them to work the same way. If i have some time I’ll experiment this week.
Joe, this is the reason I asked about the dashboard loading slowly. I found that something hangs when trying to do an ajax request to the configured hostname. The solution is to make sure the hostname is present in /etc/hosts and pointing to the machine’s IP address.
Cool. I’m still going to poke at it this week but was hoping there might have been something that stood out for you since you’ve done the most manual install testing on newer releases.
Everything came up fine, quick dashboard load, added an extension, reload… ugh
In ps ax I spotted a hanging gpg process.
The problem is with the signature check routine. DNS for “pool.sks-keyservers.net” is absent and this is the first keyserver that FreePBX tries. The reload hangs because lookup fails.
Here’s a simple workaround: add “127.0.0.1 pool.sks-keyservers.net” to your /etc/hosts file. Then the lookup succeeds and the connection fails immediately and the signature checker tries another keyserver in the list.
After I did this, reloads were a more normal 5-8 seconds.
For reference, here is the keyservers list (from libraries/BMO/GPG.class.php):
// List of well-known keyservers.
private $keyservers = array(
"pool.sks-keyservers.net", // This should almost always work
"hkp://keyserver.ubuntu.com:80", // This is in case port 11371 is blocked outbound
"pgp.mit.edu", // Other random keyservers
"keyserver.pgp.com", // Other random keyserver
"pool.sks-keyservers.net"
); // Yes. sks is there twice.
“this should almost always work”… Not currently!
Yeah, that did it. I mean more like 10-12 seconds since the timeout is 10 seconds at least. But it ain’t minutes. Of course I’m testing remotely, I test it from a local system when I can.
This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.
Update 2021-06-21 : Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.
