Distro stuck at booting when no internet connection

Hi All,

When our Distro has no internet connectivity, the boot process is stuck at “Starting Asterisk”.
How can we set a timeout on this so the OS can finish the boot process?

We are running multiple FreePBX Distro installations and are experiencing the same issue on all of them.

In a disaster recovery scenario, we can only change the IP settings manually when the OS is fully booted & we are able to login via console.

Thanks for your help!

3 Likes

This problem exists already for a long time.
We have a test scenario with a failover network. If the machine has no Internet on boot, the httpd service stucks and asterisk service does not start.

Ii think there has to be an active connection on boiot also to let Sangoma check your licensed modules.

But i dont know the real reason why everything crashes and gets stuck without active WAN connection.
Only the active eth connection is not enough, i definitly need also Internet on boot.

1 Like

That’s kinda a big deal if you have a couple PSTN lines in an emergency situation and for some reason you have to or did reboot your machine.

Hello Matthias,

Here we don’t have an issue with Httpd being stuck, only with Asterisk…

I would think there is some kind of timeout after 15sec or so, but it’s not the case.

In a disaster scenario, this is indeed bad.

I assume that Asterisk is being started as root, it needs to be started with the asterisk user IIRC.

Asterisk is being started as asterisk user yes…

Anyone knows how to add a timeout or something?

The timeout here is 10 seconds. Since your screenshot shows 2 minutes it’s past the point of being able to effectively control the timeout.

Maybe play with the systemd timeouts? on the freepbx.service

/usr/lib/systemd/system/freepbx.service

TimeoutStartSec, TimeoutStopSec or TimeoutSec (systemd.service)

So what’s the solution then, how can I fully boot a distro machine without internet connectivity?

Thanks for helping out Andrew.

It shows 2 minutes, but will end up in and endless loop… so after 2 minutes it shows 3 minutes etc etc.

How can we make sure the timeout is more robust?

You can’t. Freepbx waits for asterisk to emit the event “fully booted” if we skip that step other processes afterwards break. The timeout you want would skip that part.

I see. But a possible solution would be: If FreePBX doesn’t receive a “full booted” event after X seconds, keep all FreePBX/Asterisk related services stopped?

So. Effectively. You’d never be able to start any freepbx process then.

No, I would have console access to change (fix) the network adapter settings and be able to reboot the machine.

If it then boots, it will receive a “full booted” event because the internet connection is available again… and all is good :slight_smile:

I’m confused what the system behavior is.
Asterisk/FreePbx systems will not boot if there is no internet? We have some pstn lines that would still work and would have those coming into a Pbx

I would run a job after reboot (crontab @reboot) which waits for x minutes and checks, if all services are started. if not, you could have your ip configured automatically by the script and reboot again.
regards,
astrakid

I could try yes… but I don’t understand why it’s not taken care of in FreePBX. (in the event listener for “Fully Booted”)

This way it doesn’t look like a robust solution in a DRP scenario.

Does anyone know a way to set a “hard timeout” on this startup process?

In my point of view, 30sec should be sufficient.

Currently we are not able to login to console when there is no internet connection.
it means we cannot login to the console to fix the connectivity issue.

Thanks a lot!

This has come up before - I recommend checking to see if a Feature Request has been submitted, and if so, upvote it. If not, it might be a good suggestion.

IIRC, there are technical reasons why Sangoma wants this “phone home” feature to remain intact, but there are lots of environments (I’m using two) where Internet Access is inconsistent with proper operation of the network.