SOLVED NTP Issue

[tavi]

Hello everyone,

I think I have an issue with NTP on my brand new TrueNAS scale build.
First, I saw the issue on the reporting tab, all date was 8hrs behind, I have to zoom out to see the graphs.
On my console I have the following:

Code:

admin@truenas[~]$ timedatectl status
               Local time: Fri 2023-03-17 00:24:48 EET
           Universal time: Thu 2023-03-16 22:24:48 UTC
                 RTC time: Thu 2023-03-16 22:24:48
                Time zone: Europe/Bucharest (EET, +0200)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no
admin@truenas[~]$ 

In the Web UI, if I make any change, no matter how small to NTP servers, I can issue NTPQ -p with no problems.
BUT, right after this, I get "Connection refused".

Code:

admin@truenas[~]$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time1.google.co .GOOG.           1 u    1   64    1   41.165  +287937   0.000
 ntp3.rdsnet.ro  10.199.226.96    2 u    1   64    1    7.202  +287937   1.807
 185.86.67.2     207.197.87.124   4 u    2   64    1    6.135  +287937   0.000
 time01.nevondo. 192.53.103.108   2 u    1   64    1   39.386  +287937   2.605
 time.cloudflare 10.50.9.33       3 u    1   64    1    6.246  +287937   1.217
admin@truenas[~]$ ntpq -p
ntpq: read: Connection refused
admin@truenas[~]$ 

Is the above behavior normal?

I have asked my ISP to unblock port 123 which they did.

Thank you!

 

[tavi]

Another thing, in my netdata dashboard, I can see some time sync error:

Local time is always 8hrs ahead.

Code:

admin@truenas[~]$ date
Fri Mar 17 02:45:43 EET 2023

 

[elvisimprsntr]

time1.google.co .GOOG. 1 u 1 64 1 41.165 +287937 0.000

Welcome

Your offsets might be too large to sync.

Q1. Are you virtualizing this system or running on bare metal?
Q2. Did you install on a system which was previously running Windows?

Linux/FreeBSD stores time in UTC time. Windows stores in local time.

A1. Did you set up nameserver and default route in Network -> Global Configuration? Should be the IP of your router/firewall.
A2. You may need to enter the BIOS and manually set the CMOS clock to UTC time.
A3. Or manually set the time using the "date" command
A4. You may also want to check the CMOS battery voltage (replace if anything less than 3.0 volts) or simply replace the CMOS battery

 

[tavi]

Thank you @elvisimprsntr.

A1. Did you set up nameserver and default route in Network -> Global Configuration? Should be the IP of your router/firewall.

Q1. Are you virtualizing this system or running on bare metal?

Bare metal, is a new build.

Q2. Did you install on a system which was previously running Windows?

Yes. I previously had Win11 to test the hardware while building it. I don't have much Linux experience.

A1. Did you set up nameserver and default route in Network -> Global Configuration? Should be the IP of your router/firewall.

Default route was set up to my router IP, now I also added the nameserver. -> same result.

A3. Or manually set the time using the "date" command

I have tried now this also, same result.

But, I have now changed TZ to London and set up time with "date" to match RTC.

Code:

admin@truenas[~]$ timedatectl
               Local time: Fri 2023-03-17 02:45:22 GMT
           Universal time: Fri 2023-03-17 02:45:22 UTC
                 RTC time: Fri 2023-03-17 02:46:25
                Time zone: Europe/London (GMT, +0000)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no
admin@truenas[~]$ 

Still, on reporting tab, there is that 8 hour time difference:

A2. You may need to enter the BIOS and manually set the CMOS clock to UTC time.
A3. Or manually set the time using the "date" command
A4. You may also want to check the CMOS battery voltage (replace if anything less than 3.0 volts) or simply replace the CMOS battery

Thank you for this, I will try this also once I get to the hardware.

 

[tavi]

Hi,

After changing the BIOS time to match UTC, the reporting works and also I can sicccessfully issue NTPQ -p command.
However, NTP seems still not syncing.

 

[elvisimprsntr]

However, NTP seems still not syncing.

It is still polling the NTP servers. Wait for reach=377. It will take 5-10 minutes

 

[tavi]

Well, you are right :)

Thank you!