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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1771080
Title:
gpsd should start after chrony if they are being used together
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1771080/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
