There is a time synchronization problem with your system

[bbakirtas]

hi i got 2 server 1 server has db and web server 1 server asterisk
servers
VERSION: 2.8-422a
BUILD: 140117-0840
Asterisk 1.8

my problem is "There is a time synchronization problem with your system, please tell your system administrator"

screen -ls asterisk server

Code: Select all

There are screens on:
        1453.ASTfastlog (Detached)
        1450.ASTVDremote        (Detached)
        1447.ASTVDauto  (Detached)
        1444.ASTlisten  (Detached)
        1441.ASTsend    (Detached)
        1438.ASTupdate  (Detached)
        1326.asterisk   (Detached)
        1321.astshell20141218185721     (Detached)
8 Sockets in /var/run/screens/S-root.


screen -ls web server

Code: Select all

There are screens on:
        1931.ASTemail   (Detached)
        1929.ASTVDautoFILL      (Detached)
        1927.ASTVDadapt (Detached)
3 Sockets in /var/run/screens/S-root.


server's GMT = -5.00 default

carrier configs

Code: Select all

[manuel]
disallow=all
allow=ulaw
allow=alaw
allow=g729
type=friend
username=username
secret=password
host=server
dtmfmode=rfc2833
fromhost=server
fromuser=username
insecure=port
nat=yes
allowguest=no

extensions

Code: Select all

exten => _X.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _X.,2,Dial(SIP/${EXTEN}@manuel,,tTo)
exten => _X.,3,Hangup

login logout asterisk logs

Code: Select all

Connected to Asterisk 1.8.23.0-vici currently running on teleast (pid = 1332)
Verbosity is at least 21
[Dec 18 19:40:45]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 18 19:40:45]   == Using SIP RTP CoS mark 5
[Dec 18 19:40:46]        > Channel SIP/1001-0000000c was answered.
[Dec 18 19:40:46]     -- Executing [8600051@default:1] MeetMe("SIP/1001-0000000c", "8600051,F") in new stack
[Dec 18 19:40:46]   == Parsing '/etc/asterisk/meetme.conf': [Dec 18 19:40:46]   == Found
[Dec 18 19:40:46]   == Parsing '/etc/asterisk/meetme-vicidial.conf': [Dec 18 19:40:46]   == Found
[Dec 18 19:40:46]     -- Created MeetMe conference 1023 for conference '8600051'
[Dec 18 19:40:46]     -- <SIP/1001-0000000c> Playing 'conf-onlyperson.gsm' (language 'en')
[Dec 18 19:40:47]   == Manager 'sendcron' logged off from 127.0.0.1
[Dec 18 19:40:59]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 18 19:40:59]     -- Hungup 'DAHDI/pseudo-167815915'
[Dec 18 19:40:59]   == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/1001-0000000c'
[Dec 18 19:40:59]     -- Executing [h@default:1] AGI("SIP/1001-0000000c", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Dec 18 19:40:59]     -- <SIP/1001-0000000c>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16--------------- completed, returning 0
[Dec 18 19:40:59]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 18 19:40:59]     -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-0000000c;2", "8600051,K") in new stack
[Dec 18 19:40:59] WARNING[6276]: app_meetme.c:4789 admin_exec: Conference number '8600051' not found!
[Dec 18 19:40:59]     -- Executing [55558600051@default:2] Hangup("Local/55558600051@default-0000000c;2", "") in new stack
[Dec 18 19:40:59]   == Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-0000000c;2'
[Dec 18 19:40:59]     -- Executing [h@default:1] AGI("Local/55558600051@default-0000000c;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Dec 18 19:40:59]     -- <Local/55558600051@default-0000000c;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16--------------- completed, returning 0
[Dec 18 19:41:00]   == Manager 'sendcron' logged off from 127.0.0.1
[Dec 18 19:41:00]   == Manager 'sendcron' logged off from 127.0.0.1
[Dec 18 19:41:01]   == Manager 'sendcron' logged on from 127.0.0.1
[Dec 18 19:41:01]   == Manager 'sendcron' logged off from 127.0.0.1
[Dec 18 19:41:01]   == Manager 'sendcron' logged on from 127.0.0.1


where is problem?

[mflorell]

Go to the Reports web page in admin.php, then click on the plus "+" sign at the top of the servers table at the bottom and you will see the times of all servers, the DB and PHP. Do they all match up?

[bbakirtas]

servers times same

[bbakirtas]

my asterisk server active and its working?

[mflorell]

Are your servers ntp time synchronized to the same master time server?

[dragn-fire]

I'm having a similar issue, running goautodial 3.3-14 (vicidial 2.9-441a build 140612) on both servers. 1 dialer server (ip .168) & 1 db server (ip .40). db server is getting ntp time updates, dialer(.168) shows getting time from .40 when I do a ntpq -p.

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.40 206.108.0.133 2 u 984 1024 377 0.269 11.136 7.776
LOCAL(0) .LOCL. 10 l 51 64 377 0.000 0.000 0.001

In vicidial server stats reports the Dialer / PHP time / DB time are exact same but the DB server (.40) is red and time is off by almost 7 hours. Any idea where I should check to see what's causing this?

/etc/ntp.conf on dialer (.168) has: server 192.168.2.40 iburst so pretty sure ntp is configured correctly.

thanks

DF

[williamconley]

I'm having a similar issue, running goautodial 3.3-14 (vicidial 2.9-441a build 140612) on both servers. 1 dialer server (ip .168) & 1 db server (ip .40). db server is getting ntp time updates, dialer(.168) shows getting time from .40 when I do a ntpq -p.

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.40 206.108.0.133 2 u 984 1024 377 0.269 11.136 7.776
LOCAL(0) .LOCL. 10 l 51 64 377 0.000 0.000 0.001

In vicidial server stats reports the Dialer / PHP time / DB time are exact same but the DB server (.40) is red and time is off by almost 7 hours. Any idea where I should check to see what's causing this?

/etc/ntp.conf on dialer (.168) has: server 192.168.2.40 iburst so pretty sure ntp is configured correctly.

thanks

DF

1) Goautodial cluster? This is not a good idea. But OK: Let's go with that for now.
2) How did you cluster the servers? (Link to the online instructions or ...?)
3) If the servers are syncing using ntp, and "something" shows exact same time, but one server is red and time is off, then someone is lying. Perhaps you should post a simultaneous listing of all these times and time zones. ntpq -p output from both servers. The actual output from the report showing those "same times", and just for fun the time zone settings from BOTH OSs and php.ini files (including the full path and name of each file, to be sure you're not grabbing the wrong data). If none of that results in Joy ...
4) Are you certain that the mysql client on the dialer can get through the firewall to the DB server successfully? Test from the CLI.
5) May be a good idea to describe your network configuration while you're in there.

But mostly: Reinstall with Vicibox 7.0.2 (and upgrade your DB to match) or with 6.0.4 or 5.0.3, the highest one that your code will support (which is determined by your Asterisk version! Earlier code will not support an asterisk version above its head, which is why you can't use 7.0.2 with Asterisk 11 with Vicidial 2.8 which only supports asterisk up to 1.8 ). Using the Standard Installer will provide clustering for you ... neat and tidy. Thanks Kumba.

[dragn-fire]

1) Goautodial cluster? This is not a good idea. But OK: Let's go with that for now.

How did you cluster the servers? (Link to the online instructions or ...?)

This is not a new setup and was running fine for quite some time, this is a new developement with the time issue and agents are now having many random audio issues (which I suspect is due to this timing issue). At the time we used the following guide as setup: http://www.poundteam.com/downloads/Vici ... v1%201.pdf

3) If the servers are syncing using ntp, and "something" shows exact same time, but one server is red and time is off, then someone is lying. Perhaps you should post a simultaneous listing of all these times and time zones. ntpq -p output from both servers. The actual output from the report showing those "same times", and just for fun the time zone settings from BOTH OSs and php.ini files (including the full path and name of each file, to be sure you're not grabbing the wrong data). If none of that results in Joy ...

From db server:
[root@go ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*kirdu.smartacti 213.251.128.249 2 u 299 1024 377 10.328 1.968 0.265
-sys.meinwald.in 206.186.121.125 3 u 293 1024 377 9.074 -8.239 0.012
+vexx.wtfismyip. 24.150.203.150 2 u 238 1024 377 25.763 0.619 0.707
+ns507230.ip-192 137.146.28.85 2 u 252 1024 377 10.567 2.977 0.383
LOCAL(0) .LOCL. 10 l 41 64 377 0.000 0.000 0.001

From dialer server:
[root@go ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.40 192.95.25.79 3 u 221 1024 377 0.251 2.778 1.736
LOCAL(0) .LOCL. 10 l 31 64 377 0.000 0.000 0.001

when I issue the "date" command both show exact same time and timezone
[root@go ~]# date
Sat Apr 16 12:44:46 EDT 2016

4) Are you certain that the mysql client on the dialer can get through the firewall to the DB server successfully? Test from the CLI.

yes, I did mysql -h 192.168.2.40 -u cron -p*** and was able to connect to database from dialer.

5) May be a good idea to describe your network configuration while you're in there.

all internal (dialer server (192.168.2.168) / db server (192.168.2.40) and agents (using softphones) are located on the 192.168.2.X network, no external connections. Sophos FW.

But mostly: Reinstall with Vicibox 7.0.2 (and upgrade your DB to match) or with 6.0.4 or 5.0.3, the highest one that your code will support (which is determined by your Asterisk version! Earlier code will not support an asterisk version above its head, which is why you can't use 7.0.2 with Asterisk 11 with Vicidial 2.8 which only supports asterisk up to 1.8 ). Using the Standard Installer will provide clustering for you ... neat and tidy. Thanks Kumba

If I perform an upgrade would any settings be lost and have to be re-configured? Servers are running goautodial 3.3, asterisk 1.8.23.0 (vicidial version 2.9-441a biuld: 140612-1628)


Really appreciate your helping with this, I just can't seem to figure it out.

Thanks

DF

[williamconley]

If you've turned red something is obviously wrong. The time showing different could be an actual "time wrong!" or it could be that the server has lost contact and has not updated it's time for a while. But since it's the DB server that's Red ... it may be something as simple as missing processes. Are all your screens running? HD full? Crashed tables? Entries in /var/log/messages or /var/mail/root which may indicate what's crashing on the DB server?

If you upgrade you should lose nothing. If you build a whole new server and copy the DB into the new server, then upgrade the DB to match the version of Vicidial you installed (instructions in the UPGRADE document of the freshly installed server in /usr/src/astgguiclient/trunk), you will lose only customizations to any Vicidial scripts ... which would not be present in the new server anyway. But everything else (users, leads, campaigns, phones) should come along for the ride. And the original server is still intact ... just in case.

Always build the server, certify it (make sure it works with sound in both directions in Autodial mode on a fake campaign). Then put in your DB and upgrade the DB to match. Then modify Admin->Servers since that record will still reflect the prior server (such as the Asterisk version?). Good idea to screenshot this page when you certify it before the upgrade. This way you know what to put in the asterisk version, and can check for any other differences.

Once that works, you can add a 2nd and 3rd (4th? 5th?) server with the Vicibox installer any time you get bored without having to use that very old Multi-Server manual (still valid, but Kumba has made this so much easier! LOL).