There is a time synchronization problem with your system, please tell your system administrator
In case you have this error upon installation or upgrade your Vicibox/Vicidial check the following:
timedatectlutility make sure server’s timezone is set correctly and server’s date/time is correct. Set proper timezone if needed
- Check that timezone is correct in
/etc/php7/apache2/php.ini. Set proper timezone if needed and restart Apache
- If it did not help check and compare time values in Vicidial database, server time and PHP time. Use the following command:
# echo "SELECT server_ip, UNIX_TIMESTAMP(last_update),UNIX_TIMESTAMP(db_time) from server_updater" | mysql -uroot asterisk && php -r "date_default_timezone_set('America/New_York'); echo 'php time: '.date('U');" && echo ""
Specify your timezone in the command above. This should output three values that must be the same.
If DB time is wrong it means that
/usr/share/astguiclient/AST_update.pl script does not update DB value. Try to launch it manually and check for output.
If it throws error:
pattern match timed-out at /usr/share/astguiclient/AST_update.pl line 470
The code at line 470 is a “waitfor()” function that is attempting to match the response from the Asterisk server with a regex pattern but the response from the server doesn’t match the regex pattern.
Patch the file:
in two places near line 470 and near line 534 replace:
then make sure
AST_update.pl can run and DB time value is updated.
It expects only 0123 at the end while Asterisk Manager responses with:
# telnet 127.0.0.1 5038
Connected to 127.0.0.1.
Escape character is '^]'.
Asterisk Call Manager/2.10.<strong>5</strong>
Another way to patch:
Replacement: $t-waitfor(‘/Asterisk Call Manager.+\n$/’);
Check the following files for this issue and patch them as well:
AST_manager_listen.pl – line 237
AST_manager_listenBUFFER.pl – line 236
/usr/share/astguiclient/AST_update.pl runs in a separate detached “ASTupdate” screen and can be accessed as:
# screen -r ASTupdate
maybe you will need to kill it and start it up again after your database changes was made
To see the list of screens:
# screen -ls
There are screens on:
7 Sockets in /run/screens/S-root.