[Bug 1771080] Re: gpsd should start after chrony if they are being used together

[ Christian Ehrhardt ]

Hi Mark,
today I'm not answering on my own, instead the Debian maintainer Vincent Blut already contacted me on this bug (as he has issues with Launchpad to answer on his own), so I'm forwarding his message:

"The fact that the gpsd.service mentions “After=chronyd.service” should
not be an issue because when I created the chrony.service unit file for
Debian, I set chronyd.service as an alias (i.e., Alias=chronyd.service),
so the gpsd unit is correct on this front."

---

>From here on I'm is myself again :-)
As reference, from /lib/systemd/system/gpsd.service
  # Needed with chrony SOCK refclock
  After=chronyd.service
And from /lib/systemd/system/chrony.service
  Alias=chronyd.service

So systemd-wise gpsd should start after chrony(d) as intended.

I assume you were running into issues with this setup that made you
checking the service dependencies? So what happened exactly, gpsd didn't
find the socket I assume?

If that is the case I have an assumption what the reason could be thou.
The definition of a type=forking unit is that it waits until the master PID it spawned exits signalizing that the init is complete.
Now for the MAAS and general issue that we want the server portion of chrony to run nice and clean without the user wrestling with the config we use a wrapper script that might  (or not) add options.
I could think of this wrapper returning before chrony itself is fully set up, by that there could be a race where chrony is still initializing and the socket is not yet around while gpsd is already starting up and fails to find it.

To test this - if the issue is reproducible, one could exchange in the chrony service file
  ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS
with
  ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
If that makes it reliably working then we have to augment our script to properly wait.

It is a tight race thou, as the forking even on my overloaded laptop
returns in 0m0.003s - 0m0.008s real time - anyway CPUs are fast and it
is the best theory we have until you report more details on the issue
you are seeing.

Hmm, actually I checked in detail how our wrapper script is working and
it ends with the call to chronyd (to get its RC). But that implies it
will only end the shell script when the program is done. So the
theoretical race I have thought of does not exists.

Never the less there might not be an issue with our wrapper, but instead with chrony itself just returning its start PID too early before having set up the socket.
We could check that in your setup via appending
  rc=$?
  sleep 5s
  exit $rc
to the tail of /usr/lib/systemd/scripts/chronyd-starter.sh
That would grant it (for debugging) some more init time.

Note: in gpsd code I found that the socket path it will open depends on the device.
So if you use gpsd on ttyS0 then /var/run/chrony.ttyS0.sock is ok, but if you have anything else like ttyUSB0 then the path will differ.
From:
        (void)snprintf(chrony_path, sizeof (chrony_path),"/var/run/chrony.%s.sock", basename(session->gpsdata.dev.path));
Below that is a bunch of log messages:
       "PPS:%s chrony socket %s doesn't exist\n",
       "PPS:%s connect chrony socket failed: %s, error: %d, errno: %d/%s\n",
       "PPS:%s using chrony socket: %s\n",

If not printed by dfeault in gpsd you might want to set -D in
GPSD_OPTIONS in /etc/default/gpsd

I'll wait for your feedback if we look at a race or a gpsd config issue
or something completely else - setting the status to incomplete until
then.

** Changed in: gpsd (Ubuntu)
       Status: New => Incomplete

** Changed in: chrony (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gpsd in Ubuntu.
https://bugs.launchpad.net/bugs/1771080

Title:
  gpsd should start after chrony if they are being used together

Status in chrony package in Ubuntu:
  Incomplete
Status in gpsd package in Ubuntu:
  Incomplete

Bug description:
  When using GPSD to provide a time signal over a socket to chrony, it
  is necessary to start gpsd after chrony (I think this is so that gpsd
  finds the /var/run/chrony.ttySX.sock file when it launches). gpsd
  tends to want to drop privileges quickly which makes it hard for it to
  find this file later, aiui.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1771080/+subscriptions