VoIP, Linux, Security & much more fun
If you need any help regarding these subjects do not hesitate about sending me a text

I have found that sometimes when you run out of database handlers, FreeSWITCH does not know how to handle this situation gracefully. There are many reasons why this could happen; in my case the XML Handler written in LUA does not know how to recover, connections were held open and sooner than later the FreeSWITCH started to complain.

Root fix cause is a little more complex than expected. So I wrote this workaround.

#!/bin/sh
PORT=8021

/usr/bin/fs_cli -H localhost -P $PORT -x status > /dev/null
RETVAL=$?

if [ $RETVAL -ne 0 ]; then

/usr/sbin/service freeswitch start &> /dev/null
/usr/bin/sleep 15s
fi

/usr/sbin/service freeswitch status
RETVAL=$?
if [ $RETVAL -eq 3 ]; then
/usr/sbin/service freeswitch start &> /dev/null
fi

This script will try to connect to the FreeSWITCH event socket by using the fs_cli tool if it doesn't answer, it will try to start the FreeSWITCH daemon. As a second security step, it will review the service status if the return value is 3 (no started) it will try to start it again.

You should put this script in a crontab.This would be kind of high availability stuff, if for a reason your daemon goes down, crontab will try to recover it on the next minute.

Change the paths to your distribution. I have tested it in Centos 6 and 7.

Enjoy!

blog comments powered by Disqus
If you need more help than the free one provided here...