Cannot get computer clock to tell correct time

tfg99 · 10-01-2018, 04:39 PM

Hi all,

So.. I've spoken to someone who seems to know what they're talking about, and they've given me an ip address to use for the time server.

When I look online it shows that server details are in the /etc/ntp.conf file (https://access.redhat.com/solutions/58025). I don't have such a file, so I created one, added in the server ip and then restarted ntp using 'sudo systemctl restart ntpd'. However, the time is still wrong. Is there something else I should be doing? I restarted ntp 15 minutes ago.

Jack

michaelk · 10-01-2018, 04:55 PM

Try this.

As root:
Stop ntp

set time using ntpdate using and the IP address of the time server.
ntpdate server_IP_address

tfg99 · 10-01-2018, 05:04 PM

Quote:

Originally Posted by michaelk

Try this.

As root:
Stop ntp

set time using ntpdate using and the IP address of the time server.
ntpdate server_IP_address

Thanks. I kept searching on the net, and it turns out I had to force an update, ignoring the large offset of 4.5 hours, using 'ntpd -gq'. I did that, restarted ntp and now everything looks good!

Code:

ntp $ timedatectl
      Local time: Mon 2018-10-01 15:02:08 PDT
  Universal time: Mon 2018-10-01 22:02:08 UTC
        RTC time: Mon 2018-10-01 17:35:55
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2018-03-11 01:59:59 PST
                  Sun 2018-03-11 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2018-11-04 01:59:59 PDT
                  Sun 2018-11-04 01:00:00 PST

If this fixes the problem then I'm delighted! I'll have to wait until tomorrow to check the time isn't drifting. Thanks for all the help everyone. It's so nice being able to see the correct time!!!

Jack

michaelk · 10-01-2018, 05:13 PM

If you installed ntp via yum it should of created a default ntp.conf file and the startup script to be configured with the -gq options.

I guess I didn't ask the correct questions but good that it is working...

tfg99 · 10-01-2018, 05:17 PM

Quote:

Originally Posted by michaelk

If you installed ntp via yum it should of created a default ntp.conf file and the startup script to be configured with the -gq options.

I guess I didn't ask the correct questions but good that it is working...

Yeah, it's weird because I had no ntp.conf file and no drift file. Well, at least not anywhere I could find them. When I initially tried to install ntp with yum, it said it was already installed. Anyway, it seems to be working at the moment!

Jack

scasey · 10-01-2018, 05:49 PM

On CentOS 7.x the config file is at /etc/ntp.conf
I learned that from man ntp.conf

Glad you got it working.

tfg99 · 10-02-2018, 11:43 AM

Well, I got in this morning and the correct time currently is 09:40 and my computer clock says 08:55! Here are some outputs:

Code:

~ $ systemctl status ntpd.service
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2018-10-01 15:00:44 PDT; 17h ago
  Process: 41729 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 41732 (ntpd)
   CGroup: /system.slice/ntpd.service
           └─41732 /usr/sbin/ntpd -u ntp:ntp -g

Code:

~ $ timedatectl
      Local time: Tue 2018-10-02 08:55:33 PDT
  Universal time: Tue 2018-10-02 15:55:33 UTC
        RTC time: Tue 2018-10-02 16:18:11
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2018-03-11 01:59:59 PST
                  Sun 2018-03-11 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2018-11-04 01:59:59 PDT
                  Sun 2018-11-04 01:00:00 PST

Code:

~ $ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 137.78.0.117    137.78.212.19    2 u   52   64  377    8.576  2673234 12203.3

Code:

~ $ ntpdate -q 137.78.0.117
server 137.78.0.117, stratum 2, offset 2691.765517, delay 0.02805
 2 Oct 08:57:08 ntpdate[48715]: step time server 137.78.0.117 offset 2691.765517 sec

The last output is interesting. It says "2691.765517 sec" which is indeed how many seconds my computer clock is off from the real time. So if it knows this, why doesn't it correct it and change it? And why, if all this seems to be set up, does timedatectl show 'NTP enabled: yes' but 'NTP synchronized: no'?

Why is it so confusing to get a clock to tell the right time??!!!

Jack

michaelk · 10-02-2018, 12:47 PM

ntp is complicated... Depending on the offset ntp tries to slowly slew time to be correct instead of just simply applying a time correction. Some services do not like time jumps.

Without knowing anything about your timer server provided by IT it is difficult to say what is happening. How is that server synced to a time source? Was the jitter a larger value yesterday when you were first synced to the server?

Did you look at the output of ntpq command yesterday? Once reach = 377 and your computer syncs you should hopefully see an * in front. That means it is using the server although with only one it should be by default. With a big jitter value the computer may not use the server at all.

Code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-192.168.0.2     204.9.54.119     2 u  996 1024  377    0.150    7.634   0.942
+198.251.90.140  216.218.254.202  2 u  746 1024  377   61.677    0.979   2.940
+72.5.72.15      162.213.2.253    2 u  849 1024  377   71.496    2.124   0.956
*198.60.22.240   .XMIS.           1 u  173 1024  375   63.064   -1.335   1.923
-12.167.151.2    198.148.79.210   3 u  906 1024  377   31.252   10.339   0.682

A brute force fix would be to disable ntp and run ntpdate as a system cron task every 10 minutes or so.

tfg99 · 10-02-2018, 02:03 PM

I can't remember what the ntpq output was yesterday. I was thinking about possibly making an automated command to update the time, but wasn't sure how to do it.

For now (at 12:00) I have done the following:

Code:

service ntpd stop
ntpd -gq
service ntpd start

The output immediately after is as follows:

Code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 137.78.0.117    128.149.128.18   2 u   10   64    1    5.419  556.449   0.000

      Local time: Tue 2018-10-02 11:58:40 PDT
  Universal time: Tue 2018-10-02 18:58:40 UTC
        RTC time: Tue 2018-10-02 18:08:24
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2018-03-11 01:59:59 PST
                  Sun 2018-03-11 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2018-11-04 01:59:59 PDT
                  Sun 2018-11-04 01:00:00 PST

So it says NTP is currently enabled and synchronized. I'll see how this changes in a few hours!

Jack

michaelk · 10-02-2018, 02:50 PM

reach should be at 377 now so check and post the output of ntpq again.

tfg99 · 10-02-2018, 03:01 PM

Quote:

Originally Posted by michaelk

reach should be at 377 now so check and post the output of ntpq again.

Okay We have...

Code:

~ $ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 137.78.0.117    128.149.128.18   2 u   57   64  377   21.328  145363. 12261.1

Code:

~ $ timedatectl
      Local time: Tue 2018-10-02 12:56:46 PDT
  Universal time: Tue 2018-10-02 19:56:46 UTC
        RTC time: Tue 2018-10-02 19:56:56
       Time zone: America/Los_Angeles (PDT, -0700)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2018-03-11 01:59:59 PST
                  Sun 2018-03-11 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2018-11-04 01:59:59 PDT
                  Sun 2018-11-04 01:00:00 PST

The actual UTC is 19:59, not 19:56:46. So my computer clock is slow by a couple of minutes at the moment.

Jack

michaelk · 10-02-2018, 03:12 PM

Code:

~ $ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 137.78.0.117    128.149.128.18   2 u   57   64  377   21.328  145363. 12261.1

I don't think the quality of the time server is good enough to use. We need to know the specifics of the server and how it is being synced to actual time.

At the moment the only method I can think of to keep the server sort of synced is to disable ntp and use ntpdate via a system cron task every 5 min.

tfg99 · 10-02-2018, 03:16 PM

Quote:

Originally Posted by michaelk

Code:

~ $ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 137.78.0.117    128.149.128.18   2 u   57   64  377   21.328  145363. 12261.1

I don't think the quality of the time server is good enough to use. We need to know the specifics of the server and how it is being synced to actual time.

At the moment the only method I can think of to keep the server sort of synced is to disable ntp and use ntpdate via a system cron task every 5 min.

Yeah, the only info I got off IT was to use 137.78.0.117, as that was one I was allowed to access what with the security and permissions etc. I'll let them know it's a load of rubbish! Anyway, at least I know NTP is working, it's just the server isn't any use.

Jack

tfg99 · 10-02-2018, 03:29 PM

Just a quick query. In the following output it says there is an offset of 207 seconds:

Code:

~ $ ntpdate -q 137.78.0.117
server 137.78.0.117, stratum 2, offset 207.335932, delay 0.02782
 2 Oct 13:20:49 ntpdate[52559]: step time server 137.78.0.117 offset 207.335932 sec

This 207 seconds seems to be how far off real time my computer is (13:23 computer vs 13:27 real time). So... my computer is getting time from the server, but how does it know the server is 207 seconds off? Surely for that it must know the actual real time presently? And if it knows that, why can't it make that my time?

Where does it get the offset information from? What is it comparing the server against? Just want as much info as possible before calling the dreaded IT!

Cheers,

Jack

michaelk · 10-02-2018, 03:32 PM

The -q just queries the server but does not actually set the clock and was just for testing ntp. If you run the command as root it will update the system clock but ntp needs to be stopped first.

Code:

 ntpdate 137.78.0.117

The offset is the time difference between the two computers.