Rebooting Fusion takes 30 mins

[Dee]

Hi everyone

Rebooting my fusionpbx server seem to take so long. Just about 200 phones and enouugh server capacity.

Disk & CPU usuage below 5% and service is running fine.

Issue is just reboot the fusion takes 30mins. Azure are suggesting that the issue is with fusionpbx

Any ideas how i can resolve this.

worried it wil get worse as i add more phones

 

[hfoster]

Does the FreeSWITCH log show anything at all?

You can start FreeSWITCH in the foreground too for debug purposes. Just make sure it's stopped and run 'freeswitch'.

It may also be an sqlite locking condition. When you get to a certain size, or use multitenanting you need to switch to postgresql in the core. There's a script to convert it in the fusionpbx install directory called dsn.sh.

Personally, I think FusionPBX should do this by default as I can't really think of many downsides to doing it.

 

[Adrian Fretwell]

Try stopping FreeSWITCH first (service freeswitch stop), see how long that takes, then time your reboot.

SQLite on an in-memory filing system works quite well.

 

[Dee]

Try stopping FreeSWITCH first (service freeswitch stop), see how long that takes, the time your reboot.

SQLite on an in-memory filing system works quite well.

Thank for your suggestion. What exactly do I need to do though?

Am I to install something else?

 

[Adrian Fretwell]

I'm sorry I don't really understand your question. Nothing needs installing.

 

[hfoster]

We're just guessing at the moment without logs. Your /var/log/freeswitch/freeswitch.log should detail most of what FreeSWITCH is up to, if it is FreeSWITCH which is taking a long time. You can show what took the most time to start up using:

$ systemd-analyze blame

I foolishly suggested a fix before we even know what the problem is, so ignore me for now about the core.

 

[Dee]

Thanks- here is the output of - systemd-analyze blame

 

[Dee]

I'm sorry I don't really understand your question. Nothing needs installing.

Sorry I misunderstood. You mentioned SQlite on an in-memory filing system, can you please explain what you mean please.

 

[hfoster]

Sorry I misunderstood. You mentioned SQlite on an in-memory filing system, can you please explain what you mean please.

He was replying to my comment where I suggested something before knowing what the issue is, I don't think it's pertinent however as systemd-analyze blame shows FreeSWITCH is only taking 1.9 seconds to start.

I don't think the start up is the issue which looks to be under 20 seconds, but the shutdown probably is. You may wish to see in the logs for the previous boot's shutdown:

$ journalctl -b-1 -e

Big words to look out for are 'watchdog' as that is something responsible for killing a process after 10/20 minutes of no response when shutting down.

 

[mingus]

Try this.

# fs_cli -x 'fsctl shutdown now'
# reboot

If it reboots quickly, you'll know that the shutdown routine is what is taking a long time when you try to do a normal reboot. FreeSWITCH tries to gracefully shut itself down without the 'shutdown now' command. The graceful shutdown can take a while to close all the sessions and registrations that it may have connected.

However, 30 minutes seems like an incredibly long time. How many call sessions are going through that box at any one time?

 

[Dee]

Try this.

# fs_cli -x 'fsctl shutdown now'
# reboot

If it reboots quickly, you'll know that the shutdown routine is what is taking a long time when you try to do a normal reboot. FreeSWITCH tries to gracefully shut itself down without the 'shutdown now' command. The graceful shutdown can take a while to close all the sessions and registrations that it may have connected.

However, 30 minutes seems like an incredibly long time. How many call sessions are going through that box at any one time?

Thanks okay - will try this.

I have about 100 phone registration at any given time but 0 live calls when I reboot