We've observed several times that GPS receivers would report a wrong
time/date directly after boot, probably assuming that their RTC is
correct.
Let's wait until the receiver reports it has a fix and reports actual
satellites were used to compute it.
gps-watchdog is a small tool that will connect to gpsd as a client using
libgps. If no data is received for a configurable timeout, a
configurable systemd service will be killed via 'systemctl kill'.
The idea is that this will restart gpsd, and some ExecStartPre of the
gpsd service is then re-initializing the gps receiver hardware.
In some cases, gpsd might die while we are waiting to receive a valid
fix/time information. In that case, we have to reconnect to gpsd
again and again, until a valid time has been received (and set as
system clock).
This addresses and issue when gpsdate is running and the gpsd will be
killed (testing coredump handling).
The issue is within the libgps cod itself that doesn't handle the
result(0) of the recv syscall correctly and keeps on looping. Now in a
normal system gpsdate should only execute at the beginning and exit once
there is a date. So the window for this runtime failure is quite low.
Bug reported by Holger Freyther.
When the initscript is called gpsdate it might kill itself before
it has a way to start the new gpsdate process. Use pidof with the
full path to the gpsdate binary to avoid this.
The easiest way would be to use start-stop-daemon and let it
daemonize the process and create a pid file. Because all of this
is not there and the application unconditionally daemonizes itself
I can just use killall to stop it.