For the past year or so, I’ve been battling trying to get NTP fed from GPSD. This has proven to be somewhat harder than I imagined. GPSD is supposed to feed NTP directly from shared memory, however this was not happening. I haven’t been trying to do this the entire time, but it’s been a problem for at least a year!
The simple situation is as follows: I have a device that has a GPS receiver on it in order to get the time. NTP is also running to sync the time whenever it connects to the internet(for most of the time, we are not on the network). This is also a very vanilla Debian 8 (Jessie) system on an ARM processor, so we’re not custom-compiling any of the standard packages. The GPS is also a hotplug, so we have a udev rule that calls gpsctl with the proper TTY when the USB is activated:
(udev match options here) SYMLINK+="gps%n", TAG+="systemd", ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
According to all of the literature on the web, we should just be able to do this by adding the following to /etc/ntp.conf:
#gpsd SHM server 127.127.28.0 prefer fudge 127.127.28.0 refid GPS flag1 1
(note that we are setting flag1 here, as the system that this is running on has no clock backup).
This allows NTP to read from a shared memory address that is fed by GPSD. You can check this with ntpq -p:
remote refid st t when poll reach delay offset jitter
==============================================================================
SHM(0) .GPS. 0 l - 64 0 0.000 0.000 0.000
-altus.ip-connec 193.11.166.20 2 u 7 64 1 189.620 6.525 5.288
+ks3370497.kimsu 131.188.3.222 2 u 5 64 1 186.252 17.282 14.504
+head1.mirror.ca 195.66.241.10 2 u 5 64 1 186.503 15.792 14.691
*de.danzuck.eu 192.53.103.103 2 u 4 64 1 155.953 8.786 13.366
As you can see, in this situation there is no connection to the SHM segment, but we are synced with another NTP server. However, we can verify that GPSD is running and getting GPS data by running the ‘gpsmon’ program(in the ‘gpsd-clients’ package).
The other important thing to note about the SHM segement is that the ‘reach’ value is always 0, and will never increase. You can also check the output of NTP trying to reach it with:
ntpq -p 127.127.28.0
This was very confusing to me: how are we not talking with the SHM segment? This would also seem to work on some systems, but not other systems. No matter how long I left it running, NTP would never get any useful data from the SHM segment. Finally, I stumbled across a link, which I can’t find now, that said that GPSD must be started before NTP. I then tried that on my system, by stopping my software(which is always reading from GPSD), stopping NTP and then stopping GPSD. I then started GPSD, NTP, and my software(which will also initialize the GPS system to start sending commands). This causes NTP to consistently sync with GPSD.
Do this like the following:
$ systemctl stop your-software $ systemctl stop ntp $ systemctl stop gpsd $ .. make sure everything is dead.. $ systemctl start gpsd $ systemctl start ntp $ systemctl start your-software
For reference, here’s the ntp.conf that I am using(we only added the SHM driver from the standard Debian install):
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help driftfile /var/lib/ntp/ntp.drift # Enable this if you want statistics to be logged. #statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable # You do need to talk to an NTP server or two (or three). #server ntp.your-provider.example #gpsd SHM server 127.127.28.0 prefer fudge 127.127.28.0 refid GPS flag1 1 # pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will # pick a different set every time it starts up. Please consider joining the # pool: <http://www.pool.ntp.org/join.html> server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for # details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions> # might also be helpful. # # Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end # up blocking replies from your own upstream servers. # By default, exchange time with everybody, but don't allow configuration. restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 # Clients from this (example!) subnet have unlimited access, but only if # cryptographically authenticated. #restrict 192.168.123.0 mask 255.255.255.0 notrust # If you want to provide time to your local subnet, change the next line. # (Again, the address is an example only.) #broadcast 192.168.123.255 # If you want to listen to time broadcasts on your local subnet, de-comment the # next lines. Please do this only if you trust everybody on the network! #disable auth #broadcastclient
TL;DR Having trouble feeding NTP from GPSD when you have a good GPS lock? Make sure that GPSD starts before NTP.