System time UTC is incorrect, offset computed properly

sherrellbc · 2016-07-28 11:45:47

I have never had this problem with an Arch install before. However, this time during installation I mistakenly skipped over the local section.

What I found is that the system clock is being computed properly relative to the timezone information it has (i.e. UTC to EDT, for example).

However, the current time for UTC is incorrect.

$ timedatectl 

      Local time: Thu 2016-07-28 03:38:31 EDT
  Universal time: Thu 2016-07-28 07:38:31 UTC
        RTC time: Thu 2016-07-28 07:38:31
       Time zone: America/New_York (EDT, -0400)
 Network time on: yes
 NTP synchronized: no
 RTC in local TZ: no

As you can see, UTC is shown as 07:38 and EDT is properly computed as UTC-0400, but it was 11:38 UTC when I ran this test.

In addition, the "RTC" time above does not reflect the actual Hwclock time, which is correct.

$ hwclock --debug

hwclock from util-linux 2.28
Using the /dev interface to the clock.
Last drift adjustment done at 1469623748 seconds after 1969
Last calibration done at 1469623748 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/07/28 07:42:00
Hw clock time : 2016/07/28 07:42:00 = 1469691720 seconds since 1969
Time since last adjustment is 67972 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2016-07-28 03:41:59.765274-5:00

I tried manually updating the time but was met with a failure due to NTP being enabled -- which it is not.

$sudo timedatectl set-time "2016-07-28 07:48:00"

Failed to set time: Automatic time synchronization is enabled

I tried enabling NTP, but ntpq -p reported all zeros whereas the wiki suggests that it should not be.

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 opus.bloomcount .INIT.          16 u    -   64    0    0.000    0.000   0.000
 li290-38.member .INIT.          16 u    -   64    0    0.000    0.000   0.000
 fairy.mattnordh .INIT.          16 u    -   64    0    0.000    0.000   0.000
 pool-96-248-122 .INIT.          16 u    -   64    0    0.000    0.000   0.000

The wiki also mentions that an asterisk will be prefixed to the server being used for synchronization, which I do not have. I will update with more information with ntpd decides to update the system clock.

tl;dr: UTC time reads incorrectly. This is causing the system clock and timezone offset to be computed on wrong data and subsequently produce an incorrect system time.

Last edited by sherrellbc (2016-07-28 11:55:39)

WorMzy · 2016-07-28 12:01:02

sherrellbc wrote:

I tried manually updating the time but was met with a failure due to NTP being enabled -- which it is not.

It is, it's just not syncronised:

$ timedatectl
[...]
 Network time on: yes
 NTP synchronized: no
[...]

Check why:
$ systemctl status systemd-timesyncd.service

sherrellbc · 2016-07-28 12:07:55

WorMzy wrote:

Check why:
$ systemctl status systemd-timesyncd.service

The results:

$ status systemd-timesyncd.service
   systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-timesyncd.service(8)

What is the difference between ntpd.service and systemd-timesyncd.service? I had already started/enabled the former.

After starting that service:

$systemctl status systemd-timesyncd.service
  
   systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2016-07-28 04:05:59 EDT; 4s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 1586 (systemd-timesyn)
   Status: "Connecting to time server 216.152.240.220:123 (0.arch.pool.ntp.org)."
    Tasks: 2 (limit: 512)
   CGroup: /system.slice/systemd-timesyncd.service
           └─1586 /usr/lib/systemd/systemd-timesyncd

Jul 28 04:05:59 archnix systemd[1]: Starting Network Time Synchronization...
Jul 28 04:05:59 archnix systemd[1]: Started Network Time Synchronization.

Last edited by sherrellbc (2016-07-28 12:08:54)

sherrellbc · 2016-07-28 12:43:04

My system time has not updated since I posted above (about 40 minutes).

WorMzy · 2016-07-28 13:26:35

sytemd-timesyncd is systemd's implementation of ntp. It's an alternative to ntpd, so you probably shouldn't run both. I find it interesting that was enabled but not started initially though (perhaps because it checks for ntpd?). What does 'systemctl status 'ntpd.service' say?

Try disabling systemd-timesyncd:

# timedatectl set-ntp false

You should at least be able to manually set the time then.

sherrellbc · 2016-07-28 13:46:03

I disabled the ntpd service and disabled systemd-timesyncd. I was able to change my time then:

$ timedatectl 

      Local time: Thu 2016-07-28 09:44:11 EDT
  Universal time: Thu 2016-07-28 13:44:11 UTC
        RTC time: Thu 2016-07-28 13:44:11
       Time zone: America/New_York (EDT, -0400)
 Network time on: no
NTP synchronized: no
 RTC in local TZ: no

UTC time is now somehow correct. Could this be because I updated my system clock that was on EDT?

I checked back in on the timesyncd service and found that it was timing out on network requests.

systemctl status systemd-timesyncd
  systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-timesyncd.service(8)

Jul 28 05:40:28 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 107.170.224.8:123 (1.arch.pool.ntp.org).
Jul 28 05:40:39 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 38.229.71.1:123 (1.arch.pool.ntp.org).
Jul 28 05:40:49 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 64.6.144.6:123 (1.arch.pool.ntp.org).
Jul 28 05:40:59 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 50.22.155.163:123 (1.arch.pool.ntp.org).
Jul 28 05:41:09 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 198.55.111.5:123 (2.arch.pool.ntp.org).
Jul 28 05:41:20 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 204.2.134.163:123 (2.arch.pool.ntp.org).
Jul 28 05:41:30 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 72.249.38.88:123 (2.arch.pool.ntp.org).
Jul 28 05:41:40 archnix systemd-timesyncd[1816]: Timed out waiting for reply from 104.232.3.3:123 (2.arch.pool.ntp.org).
Jul 28 05:41:42 archnix systemd[1]: Stopping Network Time Synchronization...
Jul 28 05:41:42 archnix systemd[1]: Stopped Network Time Synchronization.

Last edited by sherrellbc (2016-07-28 13:47:00)

WorMzy · 2016-07-28 14:06:25

The RTC and Universal time should share the same value, so when you manually updated the localtime it's quite likely that timedatectl automatically updated them accordingly.

Regarding the timeouts, this is probably why ntpd wasn't updating your time either. Are you able to ping those IPs? Are you blocking any ports anywhere (specifically port 123)? How is your network configured?

ewaller · 2016-07-28 15:35:01

WorMzy wrote:

sytemd-timesyncd is systemd's implementation of ntp. It's an alternative to ntpd, so you probably shouldn't run both.

It is my understanding that it is a client only version of ntp. So, if you use it ntpd, your system can act as a time server at the next stratum. It also provides an attack vector through which a bad actor could try to change your system clock.
I have found that the systemd service is a lot less finicky and (generally) just works.

sherrellbc · 2016-07-29 11:21:51

WorMzy wrote:

The RTC and Universal time should share the same value, so when you manually updated the localtime it's quite likely that timedatectl automatically updated them accordingly.
Regarding the timeouts, this is probably why ntpd wasn't updating your time either. Are you able to ping those IPs? Are you blocking any ports anywhere (specifically port 123)? How is your network configured?

I sit inside a managed network so I am unsure of its configuration. I tried to ping the address but was unsuccessful. External pinging of this address was successful, so it seems unless we have an NTP server that I am out of luck for network synchronization.

Thanks for all the help!

Arch Linux

#1 2016-07-28 11:45:47

System time UTC is incorrect, offset computed properly

#2 2016-07-28 12:01:02

Re: System time UTC is incorrect, offset computed properly

#3 2016-07-28 12:07:55

Re: System time UTC is incorrect, offset computed properly

#4 2016-07-28 12:43:04

Re: System time UTC is incorrect, offset computed properly

#5 2016-07-28 13:26:35

Re: System time UTC is incorrect, offset computed properly

#6 2016-07-28 13:46:03

Re: System time UTC is incorrect, offset computed properly

#7 2016-07-28 14:06:25

Re: System time UTC is incorrect, offset computed properly

#8 2016-07-28 15:35:01

Re: System time UTC is incorrect, offset computed properly

#9 2016-07-29 11:21:51

Re: System time UTC is incorrect, offset computed properly

Board footer