The reply used to set time at startup (option -s) is still used to adjust the clock

[JimRoewe]

Here's a log showing that the local time gets set at startup, but the original reply used to set the time is kept around and causes problems later because the offset is used relative to the correct time.

1. Start with clock set to year 2000
2. First reply says the clock is 17+ years behind
3. Local clock is updated to 2017
   3a) That reply with an offset of 17+ years is still kept.
4. More replies come in with normal offsets
5. Eventually a client_update() runs and selects that reply with a 17+ year offset
6. priv_adjtime() runs with a 17+ year offset
   6a) adjtime actually fails, but priv_adjtime ignores the error and updates all of the other replies, subtracting 17+ years
7. The replies are now full of -(17+ year) offsets

It seems like the set time option (-s) has broken for still being able to do updates. The original reply used for the local time set should be thrown away. Other in flight replies may also need to be thrown away.

Jan 1 00:00:42 ntpd[596]: constraint certificate verification turned off
Jan 1 00:00:42 ntpd[596]: adjtimex returns frequency of 0.000000ppm
Jan 1 00:00:42 ntpd[596]: ntp engine ready
Jan 1 00:00:42 ntpd[596]: adjtimex returns frequency of 0.000000ppm
Jan 1 00:00:42 ntpd[596]: writing 8.010 to drift file
Jan 1 00:00:42 ntpd[596]: adjusting clock frequency by 8.010000 to 8.010000ppm
Jan 1 00:00:42 ntpd[596]: adjtimex adjusted frequency by 8.009995ppm
Jul 6 18:26:40 ntpd[596]: reply from 216.239.35.0: offset 552680757.030447 delay 0.169737, next query 12s
Jul 6 18:26:40 ntpd[596]: set local clock to Thu Jul 6 18:26:40 UTC 2017 (offset 552680757.030447s)
Jul 6 18:26:40 ntpd[596]: reply from 216.239.35.4: offset 276340378.513884 delay 552680757.225636, next query 14s
Jul 6 18:26:52 ntpd[596]: reply from 216.239.35.0: offset 0.102681 delay 0.375845, next query 14s
Jul 6 18:26:55 ntpd[596]: reply from 216.239.35.4: offset 0.102984 delay 0.401204, next query 10s
Jul 6 18:27:05 ntpd[596]: reply from 216.239.35.4: offset 0.098295 delay 0.387953, next query 14s
Jul 6 18:27:06 ntpd[596]: reply from 216.239.35.0: offset 0.003377 delay 0.177216, next query 11s
Jul 6 18:27:18 ntpd[596]: peer 216.239.35.0 now valid
Jul 6 18:27:18 ntpd[596]: reply from 216.239.35.0: offset 0.098935 delay 0.368181, next query 10s
Jul 6 18:27:20 ntpd[596]: peer 216.239.35.4 now valid
Jul 6 18:27:20 ntpd[596]: reply from 216.239.35.4: offset 0.104147 delay 0.400189, next query 11s
Jul 6 18:27:27 ntpd[596]: reply from 216.239.35.0: offset 0.002215 delay 0.175859, next query 11s
Jul 6 18:27:32 ntpd[596]: reply from 216.239.35.4: offset 0.093294 delay 0.377498, next query 11s
Jul 6 18:27:39 ntpd[596]: reply from 216.239.35.0: offset 0.091228 delay 0.352979, next query 14s
Jul 6 18:27:42 ntpd[596]: reply from 216.239.35.4: offset 0.103587 delay 0.398571, next query 13s
Jul 6 18:27:54 ntpd[596]: reply from 216.239.35.0: offset 0.003377 delay 0.178478, next query 2464s
Jul 6 18:27:56 ntpd[596]: reply from 216.239.35.4: offset 0.089025 delay 0.369246, next query 2542s
Jul 6 19:09:00 ntpd[596]: reply from 216.239.35.0: offset 1.145930 delay 2.458820, next query 2548s
Jul 6 19:10:19 ntpd[596]: reply from 216.239.35.4: offset 0.152683 delay 0.491942, next query 2481s
Jul 6 19:10:19 ntpd[596]: adjusting local clock by 552680757.030447s
Jul 6 19:10:19 ntpd[596]: adjtime failed: Invalid argument
Jul 6 19:51:28 ntpd[596]: reply from 216.239.35.0: offset 0.106588 delay 0.376182, next query 2632s
Jul 6 19:51:41 ntpd[596]: reply from 216.239.35.4: offset -0.007241 delay 0.169028, next query 2490s
Jul 6 20:33:14 ntpd[596]: reply from 216.239.35.4: offset 1.219093 delay 2.621355, next query 2445s
Jul 6 20:35:20 ntpd[596]: reply from 216.239.35.0: offset 0.125950 delay 0.417229, next query 2441s
Jul 6 21:16:01 ntpd[596]: 1 out of 2 peers valid
Jul 6 21:16:01 ntpd[596]: bad peer time2.google.com (216.239.35.4)
Jul 7 01:13:59 ntpd[596]: failed to send query to 216.239.35.4, next query 4800s
Jul 7 01:16:01 ntpd[596]: failed to send query to 216.239.35.0, next query 4800s
Jul 7 02:34:17 ntpd[596]: reply from 216.239.35.4: offset 1.233089 delay 2.584438, next query 12s
Jul 7 02:34:29 ntpd[596]: reply from 216.239.35.4: offset 0.151555 delay 0.426392, next query 14s
Jul 7 02:34:58 ntpd[596]: no reply from 216.239.35.4 received in time, next query 300s
Jul 7 02:36:17 ntpd[596]: reply from 216.239.35.0: offset 0.133102 delay 0.390396, next query 13s
Jul 7 02:36:31 ntpd[596]: reply from 216.239.35.0: offset 0.771947 delay 1.666484, next query 12s
Jul 7 02:36:45 ntpd[596]: reply from 216.239.35.0: offset 0.740458 delay 1.606937, next query 11s
Jul 7 02:36:59 ntpd[596]: peer 216.239.35.0 now valid
Jul 7 02:36:59 ntpd[596]: reply from 216.239.35.0: offset 1.512922 delay 3.148868, next query 11s
Jul 7 02:36:59 ntpd[596]: adjusting local clock by -552680757.028232s
Jul 7 02:36:59 ntpd[596]: adjtime failed: Invalid argument

[JimRoewe]

It might be relevant, but I'm running with '-d' as well.

[Risca]

I've also encountered this issue and came up with a patch

diff --git usr.sbin/ntpd/client.c usr.sbin/ntpd/client.c
index 3de5268..5ee7ea8 100644
--- usr.sbin/ntpd/client.c
+++ usr.sbin/ntpd/client.c
@@ -402,8 +402,10 @@ client_dispatch(struct ntp_peer *p, u_int8_t settime)
            (long long)interval);

        client_update(p);
-       if (settime)
+       if (settime) {
                priv_settime(p->reply[p->shift].offset);
+               p->reply[p->shift].good = 0;
+       }

        if (++p->shift >= OFFSET_ARRAY_SIZE)
                p->shift = 0;

I've sent the patch to the OpenBSD mailing list