time changed from 2020-07-03 to 2022-05-18

[ASSI]

Udo van den Heuvel via devel writes:
> Garmin gps18x on the serial port with USB power.
> With just $GPGGA and $GPRMC enabled, so where did it find that weird date?

If you had the clockstats file enabled, you would be able to see what
message ntpd received at that point.  Since you have RMC enabled, I
guess that you got an RMC message into ntpd before it aquired a fix and
if you didn't configure anything else, I guess it starts with whatever
date the firmware was built.  I think your GPS is supposed to store the
last known position and time in Flash so this normally should not
happen, but either that function isn't enabled or it decided that the
information was unusable and did a full cold start.  Since that firmware
buils certainly was before the recorded build date of ntpd, it
(unhelpfully in this case) decides it should pivot that date forward on
the assumption you are suffering from GPS rollover issues (no it
shouldn't do that unless configured, but that's how the implementation
currently works).

>> Things should be setup such that servers from the network sanity check your 
>> GPS clock.  What's in your ntp.conf?
>
> refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.00000006 time2 0.260 baud 4800
> refclock pps unit 0 flag2 0

This is a wierd config.  You disable PPS processing on the NMEA, then
enable kernel PPS discipline and also configure a PPS refclock?

You should drop the PPS and enable PPS processing in NMEA instead, IMHO.
Set up an udev rule to intialize the GPS correctly (preferrably with
just the RMC message) and link the serial and PPS to /dev/gps0 and
/dev/gpspps0.  The Garmin has the RMI message that allows you to set the
expected time and date, so using that during the device initialization
to set it up with the current syste time & date should alleviate the
problem with it starting up with the firmware build date and warping you
into the future. 

Now, to prevent that from happening again: there are actually two
systemd targets that deal with setting up the system time.  You will
want to use time-set.target to bring up the system time to a known good
state and then time-sync.target to keep it there, which you ccan take
advantage of by using two different configs for ntpd.  The first one
potentially steps the system clock, so you should not let any
uncontrolled GPS time reach ntpd (I can generally rely on there being
enough NTP servers on my local network to converge to the correct time)
and then just exits.  The second one then never needs to step the time
since you start out very close, so you can configure the GPS there.  If
the GPS freaks out it will be marked as a falseticker and falls back to
your network instead of warping system time and if ntpd itself freaks
out it will be restarted.

ntpsec-steptime.service
--8<---------------cut here---------------start------------->8---
[Unit]
Description=Network Time Service
Documentation=man:ntpd(8)
Wants=network.target
ConditionCapability=CAP_SYS_TIME
After=network.target nss-lookup.target
Before=time-set.target
Conflicts=systemd-timesyncd.service ntpd.service chrony.service ntp-steptime.service

[Service]
Type=oneshot
PrivateTmp=true
ExecStart=/usr/sbin/ntpd -q -g -N -u ntp:ntp -c /etc/ntp-step.conf
TimeoutStartSec=60
RemainAfterExit=yes
StandardOutput=null
Restart=no

[Install]
WantedBy=time-set.target
--8<---------------cut here---------------end--------------->8---

ntpsec-ntpd.service
--8<---------------cut here---------------start------------->8---
[Unit]
Description=Network Time Service
Documentation=man:ntpd(8)
Wants=network.target time-set.target
ConditionCapability=CAP_SYS_TIME
After=time-set.target network.target nss-lookup.target
Before=time-sync.target
Conflicts=systemd-timesyncd.service ntpd.service chrony.service

[Service]
Type=forking
PIDFile=/run/ntp/ntpd.pid
PrivateTmp=true
ExecStart=/usr/sbin/ntpd -p /run/ntp/ntpd.pid -N -u ntp:ntp
Restart=on-failure

[Install]
WantedBy=multi-user.target
--8<---------------cut here---------------end--------------->8---


ntpsec-wait.service
--8<---------------cut here---------------start------------->8---
[Unit]
Description=Wait for ntpsec-ntpd to synchronize system clock
Documentation=man:ntpwait(8)
Requisite=ntpsec-ntpd.service
Before=time-sync.target
After=ntpsec-ntpd.service
Conflicts=systemd-timesyncd.service ntp-wait.service ntpd.service chrony-wait.service chrony.service
ConditionVirtualization=!container
ConditionCapability=CAP_SYS_TIME
Wants=time-sync.target

[Service]
Type=oneshot
ExecStart=/usr/bin/ntpwait -v -s 1 -n 300
RemainAfterExit=yes
StandardOutput=journal+console

[Install]
WantedBy=time-sync.target
--8<---------------cut here---------------end--------------->8---

If you've set it up correctly these should have registered as follows:
/etc/systemd/system/multi-user.target.wants/ntpsec-wait.service
/etc/systemd/system/multi-user.target.wants/ntpsec-ntpd.service
/etc/systemd/system/multi-user.target.wants/ntpsec-steptime.service
/etc/systemd/system/time-sync.target.wants/ntpsec-wait.service
/etc/systemd/system/time-set.target.wants/ntpsec-steptime.service

The ntpsec-wait will keep any services from starting that critically
depend on system time until the second (non-stepping) ntpd has
synchronized.  You may not want or need that, it usually adds around 15s
to the startup time for me.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs