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

[Gary E. Miller]

Yo Charles!

Ah, nice, much better.  I'll review it closely in the next day or two.

Hopefully some systemd people can also review it too.

On Tue, 15 Oct 2019 15:03:52 -0600
Charles Curley <address@hidden> wrote:

> 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.
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpo5doWtOjpX.pgp
Description: OpenPGP digital signature