Re: [gpsd-users] gpsd systemd troubleshooting: Draft

[Charles Curley]

Latest version is at
http://wli.ddns.info/gpsd/troubleshooting.html#systemdtroubleshooting

It has to be http; https doesn't work, so you may have to turn off https
everywhere if you have it.

It's also attached as a diff, with a slightly different date format in
the file name.


On Sat, 12 Oct 2019 17:45:11 -0700
"Gary E. Miller" <address@hidden> wrote:

> Yo Charles!
> 
> On Sun, 6 Oct 2019 13:16:07 -0600
> Charles Curley <address@hidden> wrote:
> 
> > The latest version is attached, also as a diff against the git
> > repo.  
> 
> Sorry it took so long to get to this.  I had hoped some one that uses
> systemd(ick) would have commented on this by now...

I didn't think you would pass up a chance to bash systemd. :-)


> 
> Much better,   But the order still needs work.  A reader is 3/4
> of the way into the new section before:
> 
> "+<p>The first thing, if you haven't already done so, is to install
> gpsd."
> 
> First things belong first!  Start out by stating that gpsd must
> already be installed.

Re-worked that.

> 
> Just after that you say:
> 
> "Then we verify that gpsd is running and reading from the GPS
> receiver"
> 
> One the one hand, that is, justifiably, left to other parts of the
> document, but they key part here is to help the user determine is
> systemd(estroyer) is in charge of gpsd, or not.  That is the part
> that baffles now users: how to know if systemd(ung) is in the loop,
> or not.  Give examples.

See the new h3 headings.


> 
> Which goes back to your first full paragraph:
> 
> "the gpsd hacker who wishes to troubleshoot a gpsd installation on a
> computer where systemd is present."
> 
> Many distributions have systemd(umb) present, but not running.  Gentoo
> does this to pacify some non-portable apps.  Other installs may be
> from source, so systemd(eumber) is present, and running, but not
> involved with gpsd (maybe no gpsd service file is installed).

I am learning more about systemd than I ever wanted to. Gnrrrr.....


> 
> Seems to me, after install, the next items to check are:
> 
> 1. is systemd(umbest) running?
> 2. is systemd(reck) trying to manage gpsd?
> 3. has systemd(ingleberry) started gpsd?

Did some major surgery here.


> 
> This part does not match my experience:
> 
> 
> +<p>We can kill gpsd. Systemd will restart it for us, this time with
> the options in place. We verify that the options are there:</p> +
> +<pre>root@orca:~# kill 12868
> +root@orca:~# ps aux | grep -i gpsd | grep -v grep
> +gpsd     14547  0.5  0.0  18092  3504 ?        S&lt;sl 15:44
> 0:00 /usr/sbin/gpsd -Gn +root@orca:~#</pre>
> 
> Seems to me that systemd(ank) does not do this by default.  Why would
> it restart gpsd in this case?

It seem to me to be dubious practice. For a laptop or something where
gpsd is supposed to work out of the box, it's very nice. For hacking,
it's a bloody nuisance.

It appears to be an unholy conspiracy between gpsd, udev and systemd.
This is a ublox. So, on a Debian box, using the Debian gpsd package:

root@hawk:/lib/udev/rules.d# grep 1546 *
60-gpsd.rules:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a5",
SYMLINK+="gps%n", TAG+="systemd",
ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
60-gpsd.rules:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a6",
SYMLINK+="gps%n", TAG+="systemd",
ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
60-gpsd.rules:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7",
SYMLINK+="gps%n", TAG+="systemd",
ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
60-gpsd.rules:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a8",
SYMLINK+="gps%n", TAG+="systemd",
ENV{SYSTEMD_WANTS}="gpsdctl@%k.service" root@hawk:/lib/udev/rules.d# 

Going back to the gpsd repo, I see it in gpsd.rules. But gpsd.rules.in
has:

charles@hawk:~/versioned/gpsd$ grep 1546 *
...
gpsd.rules.in:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a5",
SYMLINK+="gps%n", @udevcommand@ gpsd.rules.in:ATTRS{idVendor}=="1546",
ATTRS{idProduct}=="01a6", SYMLINK+="gps%n", @udevcommand@
gpsd.rules.in:ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7",
SYMLINK+="gps%n", @udevcommand@ gpsd.rules.in:ATTRS{idVendor}=="1546",
ATTRS{idProduct}=="01a8", SYMLINK+="gps%n", @udevcommand@ ...
charles@hawk:~/versioned/gpsd$

(I used the vendor ID for u-blox because that's what I have. Other GPS
receivers have similar.)

So it looks like something in the build process makes that
substitution, for pretty much every device in gpsd.rules.

Fortunately, dropping a suitably rename 60-gpsd.rules.in file
into /etc/udev/rules.d/ solved that problem.

I don't speak scons. Is there any way to tell scons to not build for
systemd? If so, we should document it!

> 
> To recap, imagine you step up to host that you have never seen before.
> What steps would you do?  In what order?

Maybe we should re-think this whole document as a decision tree. But
that's far removed from what I'd doing here.


> 
> Then explain each step as you go, instead of splitting the theory and
> practice into separate sections with the start nearer the end.
> 
> If you like a separate theroy doc, then that would go in the
> gpsd/systemd directory.

OK, let's see where this part of the thing goes, and then deal with the
theory stuff.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

troubleshooting.html.2019-10-15.diff
Description: Text Data

pgpSmk5xrfmWP.pgp
Description: OpenPGP digital signature