vicidial.org

ntpd no longer keeps my servers synch, after updating my svn and doing a zypper up -y

db:/etc # ntpd -q
12 May 16:42:55 ntpd[22821]: ntpd 4.2.8p6@1.3265-o Thu Apr 28 14:06:58 UTC 2016 (1): Starting
12 May 16:42:55 ntpd[22821]: Command line: ntpd -q
12 May 16:42:55 ntpd[22821]: proto: precision = 0.105 usec (-23)
12 May 16:42:55 ntpd[22821]: switching logging to file /var/log/ntp
12 May 16:42:55 ntpd[22821]: unable to bind to wildcard address :: - another process may be running - EXITING
db:/etc #

dialerOne:~ # ntpd -q
12 May 16:47:23 ntpd[14719]: ntpd 4.2.8p6@1.3265-o Thu Apr 28 14:06:58 UTC 2016 (1): Starting
12 May 16:47:23 ntpd[14719]: Command line: ntpd -q
12 May 16:47:23 ntpd[14719]: proto: precision = 0.489 usec (-21)
12 May 16:47:23 ntpd[14719]: switching logging to file /var/log/ntp
12 May 16:47:23 ntpd[14719]: unable to bind to wildcard address :: - another process may be running - EXITING
dialerOne:~ #


anyone else have this issue and a solution? I have tried restart the service a bunch of times as well.

why did you zypper up? svn up does not involve zypper.

This is an ntp issue, which may have been upgraded by the zypper request. You should troubleshoot ntp. Did you reboot? (Yes, I have to ask.)

Also: If you haven't noticed, there is a 'support' board that's a bit more suited to this support question than the "General Discussion" board in which you posted this. Moving

Hello Williamconley,

I did post in the wrong area, my apologies. Yes I did reboot as well, same issue I think the ntp daemon got updated.

so change the .conf file for ntp to default settings. Uninstall ntp and reinstall it. Something fun like that. But it's not related to Vicidial, per se.

One of our standard settings for /etc/ntp.conf

Code: Select all

driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp

server time-c.nist.gov
server time-a.nist.gov
server time-b.nist.gov
server time-d.nist.gov
server time.nist.gov
server 127.127.1.0

restrict default nomodify notrap
restrict 127.127.1.0

fudge 127.127.1.0 stratum 10

and you may need to manually set the time once to get it close enough to true time for sync to work. This code will do that plus set the HW clock:

Code: Select all

hwclock --show
/etc/init.d/ntp stop
sntp -P no -r time-a.nist.gov
hwclock -w --localtime --debug
hwclock --show
date

the time sync issue also happens due to lack of dahdi driver .
post your details like installation method, server type(virtual or physical) , vicidial version, asterisk version

post the output of the below command from linux console
screen -list
dahdi_cfg -vv

dialerOne:~ # screen -list
There are screens on:
1366.ASTVDadFILL (Detached)
1363.ASTfastlog (Detached)
1360.ASTVDadapt (Detached)
1357.ASTVDremote (Detached)
1354.ASTVDauto (Detached)
1351.ASTlisten (Detached)
1348.ASTsend (Detached)
1345.ASTupdate (Detached)
1225.asterisk (Detached)
1218.astshell20160513063335 (Detached)
10 Sockets in /var/run/screens/S-root.

dialerOne:~ # dahdi_cfg -vv
DAHDI Tools Version - 2.11.1

DAHDI Version: 2.11.1
Echo Canceller(s):
Configuration
======================


Channel map:


0 channels to configure.

dialerOne:~ #

AFAIK: There are three possibilities for time sync errors.

1) Time is actually out of sync somewhere. The OS time, DB time or PHP time could be "off" based on the time zone settings, or a 2nd server could be "off" based on the DB server's time sync/configuration. So check time according to all three, and there is a useful visual by clicking on Reports which will show server times.

2) Agent browser is dropping packets to the web server. These packets trigger a db field change that must occur on a timed basis. Dropping packets causes the value to NOT update, causing a time sync error to kill the agent session.

3) Agent is NOT in a meetme room (never got the call). This can be due to dahdi not running or any other reason that kills the call abnormally ... but if the agent hears "you are the only person in this session" during login and the call is still "live", that usually means that the meetme room is active, pushing us back to 1) and 2) above.