sort of new to Freepbx
managed to install and configure properly and work with it for just about 10 months.
i am facing an issue where the time on the server is off by 2 hours.
however, time zone settings are correct, and also configured the NTP to be directed to the appropriate NTP server.
when i run a reboot to the system, it will give it the correct time, and about 24 hours later it will get out of sync.
timdatectl shows that the NTP is not synchronized and only a reboot makes it sync properly.
anyone facing this sort of issue?
Would love it but i’m more of a windows environment and i have no idea where to take a look to find out what is wrong.
i did use an official freepbx downloaded from the freepbx website.
everything worked great up to a few days ago where i started noticing that the time is getting off…
This is what happens after restarting the service.
[root@freepbx ~]# timedatectl
Local time: Sun 2020-02-16 10:24:35 IST
Universal time: Sun 2020-02-16 08:24:35 UTC
RTC time: Sun 2020-02-16 10:24:35
Time zone: Asia/Jerusalem (IST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: no
Last DST change: DST ended at
Sun 2019-10-27 01:59:59 IDT
Sun 2019-10-27 01:00:00 IST
Next DST change: DST begins (the clock jumps one hour forward) at
Fri 2020-03-27 01:59:59 IST
Fri 2020-03-27 03:00:00 IDT
and this is how it looks when its off (and yes it’s 2 hours)
[root@freepbx ~]# timedatectl
Local time: Sun 2020-02-16 12:24:35 IST
Universal time: Sun 2020-02-16 08:24:35 UTC
RTC time: Sun 2020-02-16 12:24:35
Time zone: Asia/Jerusalem (IST, +0200)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: yes
DST active: no
Last DST change: DST ended at
Sun 2019-10-27 01:59:59 IDT
Sun 2019-10-27 01:00:00 IST
Next DST change: DST begins (the clock jumps one hour forward) at
Fri 2020-03-27 01:59:59 IST
Fri 2020-03-27 03:00:00 IDT
Figured you were israeli
thanks for this.
right now i’m testing it, will let you guys know if it works.
the zone was different than what i was able to set on the web panel so i figure it might help.
@Charles_Darwin
This is a VM, but running on ESXI 6.7 and that feature is already off
So waking up this morning seems it did not help.
it does seem now that even when the time is wrong, it states that the NTP is synced which makes me think there is something wrong that i am not getting…
also, before the change itzik provided the RTC time was the correct time, now it’s also having the offset time.
giving you guys the info i got from the commands:
This is the wrong time
[root@freepbx ~]# timedatectl
Local time: Mon 2020-02-17 09:42:54 IST
Universal time: Mon 2020-02-17 07:42:54 UTC
RTC time: Mon 2020-02-17 09:42:53
Time zone: Israel (IST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: no
Last DST change: DST ended at
Sun 2019-10-27 01:59:59 IDT
Sun 2019-10-27 01:00:00 IST
Next DST change: DST begins (the clock jumps one hour forward) at
Fri 2020-03-27 01:59:59 IST
Fri 2020-03-27 03:00:00 IDT
This is the right time after restarting chronyd service
[root@freepbx ~]# timedatectl
Local time: Mon 2020-02-17 07:43:15 IST
Universal time: Mon 2020-02-17 05:43:15 UTC
RTC time: Mon 2020-02-17 09:43:43
Time zone: Israel (IST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: no
Last DST change: DST ended at
Sun 2019-10-27 01:59:59 IDT
Sun 2019-10-27 01:00:00 IST
Next DST change: DST begins (the clock jumps one hour forward) at
Fri 2020-03-27 01:59:59 IST
Fri 2020-03-27 03:00:00 IDT
Did you check both chrony conf files, described in my link above?
If you are a Windows guy, you have to use a Linux-compatible editor, like Proton editor. FileZilla is a good ftp-client. In Filezilla settings you have to define Proton as the standard editor for all text files.
To me it looks like as if somewhere there is another ntp-sync service, which is set to the wrong time zone. Check the chrony confs…
@Charles_Darwin
i am not very sure what do i need to tweak there.
i open the files with vim, the ntp servers are correct (pointing to asia.pool.ntp.org iburst)
i will note again, if i start/restart the chronyd service, the time is being synced and everything works well.
but after a few hours (have yet to understand exactly how many hours) it becomes unsynced.
not really sure what i am doing here wrong, even re-setting the previous setting which worked for the past 10 months is not giving this a solution.
the only way i can see it right now is to run a scheduled task to push the command “service chronyd start” but as you guys say and i agree, it’s not fixing the problem.
This sounds like there maybe sometime wrong with the clock on the system that’s causing it to get really out of date fast. Is this a VM? I believe the ntpd protocol will stop updating the clock drift after the clock gets out of sync more than 15 minutes. Running the command as suggested above is the way to resolve it, but I would probably look into what is causing the clock to run fast (or slow).
If this is the latest release of freepbx, it should be using chronyd and not ntpd. You can check to see if chronyd is running by executing the following command:
systemctl status chronyd
You can also see what is running on port 123 by running the following:
netstat -tulpn | grep 123
This is a VM running on ESXI 6.7
That hypervisor is running a few more windows server vm’s and they’re working great.
the FreePbx system is very small, we’re using only 2 extensions, with a very basic ivr.
so i’m not sure what to investigate or to simply “patch it” by making some kind of a scheduled task to run every 10 minutes, i’m sure it’s not something that will make the system heavy.
these stats are after waking up at 6:45 and running the command to start chronyd so i won’t get calls early on… but i’l run it after it get’s out of sync again to check the differences.
Feb 18 08:34:31 freepbx.sangoma.local systemd[1]: Starting NTP client/server…
Feb 18 08:34:31 freepbx.sangoma.local chronyd[19049]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 +DEBUG)
Feb 18 08:34:31 freepbx.sangoma.local chronyd[19049]: Frequency -9.175 +/- 1.790 ppm read from /var/lib/chrony/drift
Feb 18 08:34:31 freepbx.sangoma.local systemd[1]: Started NTP client/server.
Feb 18 08:34:36 freepbx.sangoma.local chronyd[19049]: Selected source 192.114.62.250
Feb 18 08:34:36 freepbx.sangoma.local chronyd[19049]: System clock wrong by -7227.339335 seconds, adjustment started
Feb 18 06:34:08 freepbx.sangoma.local chronyd[19049]: System clock was stepped by -7227.339335 seconds
@amit19595 I don’t think patching it really fixes the issue. I would probably try to troubleshoot the time issue from a VMWare perspective first. From past experience, this is probably just a misconfiguration in linux or ESXI.
It’s important to keep note that windows and linux are two completely different operating systems and just because something is working great on the windows platform, doesn’t mean that things are setup great with linux.
I’ve found this article from VMWare that may help:
Also I’ve found something along the lines of time issues and VMware:
If it were up to me, I would try to eliminate that the issue isn’t with VMWare / Linux first before attempting to patch anything.
@amit19595 What does the time zone and NTP server configuration on the ESXi server look like? The guest may be configured to synchronize time with the host. That is disabled by default though so you would have had to enable time synchronization with the host for it to cause a problem here.
