Fresh install - FreeSwitch not starting correctly

nhwebforge

New Member
Sep 16, 2024
12
0
1
47
Hi

So I did a fresh install of the latest release on a new install of Debian 12 yesterday. All phones were registering but were unable to call eachother - all calls going straight to VM. I checked the SIP Status screen in FPBX and got a socket error. I restarted FreeSwitch with "systemctl restart freeswitch", refreshed the SIP Status page, all now running fine and phones are able to call eachother. I reboot the servier to check what's happening on startup. Again, no calls possible (straight to VM each time), socket error in SIP Status. This time I check systemctl status freeswitch. All appears to be running. Very odd. Restart FreeSwitch with systemctl restart freeswitch... everything works again. Checked systemctl status freeswitch and it spits out EXACTLY the same report as before the restart... word for word the same the only difference being the PID (which I presume is the process ID and will therefore be expected to be different).

Funnily enough, FPBX appears to be running smoother than ever before (once I restart FreeSwitch following a reboot). My previous installation was constantly hanging due to SQLITE "busy" messages which would block the entire server (no SSH or even local access - reboot the only option). There were a lot of BLFs in use and I'd tried in vain to get FreeSwitch to use POSTGRES but no matter which guide I followed, it would still keep using SQLITE for some things and would still block after about 15 minutes.

Anyhoo... if anyone has any ideas as to why FreeSwitch is starting but not being "seen" by FPBX, and only seems visible after a systemctl restart... I'm all ears!

Thanks in advance as always!

NH
 

markjcrane

Active Member
Staff member
Jul 22, 2018
496
177
43
49
SQLITE "busy" messages this is how SQLite works by default. When there is a write it locks the file writes the changes and unlocks the file. If something else tries to write to it while it is locked FreeSWITCH will log SQLite "busy" and say 299 this means it was busy one time. From there it waits a short time and then tries again if busy again it will decrement the value down by one and say 298. This is a normal SQLite operation. FreeSWITCH shares what is doing. It becomes a concern if the number reaches low numbers. You can SQLite to a ram drive for better performance.

As far as the operating startup issue I haven't seen this issue yet but I'll do additional testing. It sounds like FreeSWITCH started up too early in the boot cycle maybe. You should check the freeswitch logs before you restart freeswitch to see what the log is saying.

p.s. Ubuntu 24.04 LTS is now working as well and latest FreeBSD.
 

nhwebforge

New Member
Sep 16, 2024
12
0
1
47
SQLITE "busy" messages this is how SQLite works by default. When there is a write it locks the file writes the changes and unlocks the file. If something else tries to write to it while it is locked FreeSWITCH will log SQLite "busy" and say 299 this means it was busy one time. From there it waits a short time and then tries again if busy again it will decrement the value down by one and say 298. This is a normal SQLite operation. FreeSWITCH shares what is doing. It becomes a concern if the number reaches low numbers. You can SQLite to a ram drive for better performance.

As far as the operating startup issue I haven't seen this issue yet but I'll do additional testing. It sounds like FreeSWITCH started up too early in the boot cycle maybe. You should check the freeswitch logs before you restart freeswitch to see what the log is saying.

p.s. Ubuntu 24.04 LTS is now working as well and latest FreeBSD.
Evening Mark

Thanks for the info regarding SQLITE... yes, I'd read that elsewhere, but it was odd that it was causing the entire system to hang (well, die, to be fair).

I'll take a look in the logs tomorrow and report back. Is there any guidance you can provide to move FreeSwitch further down the boot order?

My intial reaction to your comment was "well surely FreeSwitch needs to start earlier than FusionPBX otherwise FPBX has nothing to look for"...

That said, when opening SIP Status, it clearly attempts to connect to the process via socket but can't find it. What is it looking for and why can't it find it (when it's clearly running and returns a valid process ID)? Just thinking out loud :)

Thanks again for your help. My latest environment has been running solid for 48 hours now (after the intial FS restart of course), which is a massive improvement over the 10 - 15 minutes before. I'll swap out the disks and try Ubuntu and FreeBSD to see if that helps. I can always go back to this semi-working version. It's a 10 phone system for a charity I help, using donated second-hand phones and an old donated Dell Precision 960 workstation as the PBX host and it's not in use 24/7 so no panic.

Good luck for the week to come.

NH