Time syncronization "Vicidial asterisk server" issue

[xenia2608]

My current configuration on which problem arises continuously
VERSION: 2.12-565a
BUILD: 160827-0917
Asterisk : 1.8.23.0
Ram : 32 GB
SSD : 200 GB and HDD 2 TB
CPU : Intel i7
core : 4
server : dedicated cloud server
OS : Centos 6.xx
Installation : Scratch install using Ray solomon guide

On this server i am facing little wired issue with time synchronization . In report section, after clicking on + sign at bottom it shows current sync time for PHP, DB and vicidial asterisk server . Some time it shows correct time in all section but some times "vicidial asterisk server" get out of sync by 10 sec or 20 sec and then suddenly soft phone gets unregistered . After some time it automatically gets corrected .

I tried to update time zone in system settings, server settings, php . Even again setup my time using

rm /etc/localtime
ln -sf /usr/share/zoneinfo/desired/Zone /etc/localtime
rdate -s time-a.nist.gov
chkconfig ntpd on
ntpdate pool.ntp.org
/etc/init.d/ntpd start

But still no luck with get it sorted out . can anyone suggest to resolve this .

Another issue, when i tried to restart asterisk server using "service asterisk restart" it shows error : Starting asterisk: /usr/sbin/safe_asterisk: line 86: ulimit: open files: cannot modify limit: Operation not permitted

I tired to change ulimit value to higher but still same issue . Then after little search i modified by putting # in first character of line 86 and 102. Now issue seems to be resolved .

My concern is . is this change going to hamper server in any way or is there any other solution .

Its my first encounter with these issue .

Thank you

[boybawang]

what is the output of screen -ls

[zoropbx]

I have seen several such issues after scratch installation..

While Scratch installation, there are chances of small errors etc. Its a good idea to ask your hosting provider to install Vicibox-7 iso on your server. That will take care of everything and you will never have any glitch.

[muyousif]

Make sure agent workstation time is also synch and it is more better if agent workstation is synch with database server for time. You can run a cron job periodically to synch time on database server. Secondly do not start asterisk directly, it is better to start or restart asterisk using the script /etc/init.d/vicidial.

[xenia2608]

Thanks for suggestion guys . I do follow each steps to verify everything .

Asterisk server Time sync Problem solved . after modifying the file /usr/sbin/safe_asterisk . seems asterisk server was causing this issue due to ulimit . This ulimit error was new to me and it took almost 3 hr to resolve this .

Can anyone provide information on, whether this change is going to hamper or downgrade asterisk performance . Its been more than 4 days server is running without any issue after this change to file /usr/sbin/safe_asterisk and all sync issue resolved . I hope it wont happen again .

If " service asterisk restart " shows error msg " Starting asterisk: /usr/sbin/safe_asterisk: line 86: ulimit: open files: cannot modify limit: Operation not permitted " , edit the file " /usr/sbin/safe_asterisk " and put # in first character of line 86 and 102 , and your asterisk ulimit error will be resolved . May be this is not correct solution , but till now my server is working fine after above change .

[williamconley]

Stock vicibox installs have this line during startup:

Code: Select all

ulimit -n 65536

That being said: If you have a multi-server system, the agent workstation time is NOT relevant to the "time sync error".

There are two causes for time sync error:
1) Servers are out of sync with one another (as you experienced, not in any way related to time on the workstations)
2) Agent workstations are dropping packets to the servers. This is not a "time" related issue, but if the packets don't return in time (due to being dropped!), then Vicidial will toss the time sync error because the result of the packet being received is a change in the DB with a timestamp. No packet = no change = timestamp gets stale = "time sync error". Convoluted, I know.

So the goals are: no dropped packets and servers in sync with each other.

Next up: Only ONE of your servers should sync to "the world". That would be YOUR master time server and should be in the same physical location as the Vicidial cluster. Many will just use the DB server for this. The rest of your servers should then sync to that server with "iburst" (for fast trusted syncing on startup). This means that your servers are synced to Each Other which is all that matters. They could be off by quite a bit, but if they all agree with one another it won't matter.

And do not "set" the time with ntpdate, as this deletes the "sync data" being used to train the server(s) to sync properly.

And try to avoid "pool" NTP services, instead use a few government or major corporate services. The "ntp pool" services are known hacker hangouts. Seriously.

Happy Hunting!