gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Charles Curley
Subject: Re: [gpsd-users] gpsd systemd troubleshooting: Third Draft
Date: Sun, 20 Oct 2019 12:32:59 -0600

On Sat, 19 Oct 2019 23:14:42 +0200
Bernd Zeimetz <address@hidden> wrote:

> Hi Charles,
> 
> to be honest: I think you should study the systemd documentation a bit
> more...

OK. Where would you suggest I start?

> 
> Just a few comments:

I am guessing (due to the lack of an "In Reply to..." line) this is a
reply to my first version. I have made some changes and resent to the
list (Tue, 15 Oct 2019 15:03:52 -0600). I made some more changes based
on your comments, and attached and reposted:

http://wli.ddns.info/gpsd/troubleshooting.html#systemdtroubleshooting

I'll ignore points that are now moot.


> 
> > +<p>Also, issuing the stop command may not actually stop the
> > service. If there is a GPS receiver plugged in, something starts
> > gpsd up again.</p>  
> 
> That won't happen if gpsd.socket is stopped. If not, plugging in a usb
> device will start it again via udev/gpsdctl.

My experience is that something (udev/gpsdctl??) restarts both units
even without (re)plugging a USB receiver.


> 
> 
> > +<p>Note that <code>systemctl disable gpsd</code> stops the
> > gpsd.socket unit from running at the next boot. It does not stop it
> > from running at the time you issue the command. For that, you
> > should stop the service. In general stop a unit before you disable
> > it. Since gpsd has two units, you should disable and enable them
> > both.</p> + +<pre>systemctl disable gpsd.socket gpsd.service<br/>
> > +&#8230;<br/> +systemctl enable gpsd.socket gpsd.service</pre>> +
> > +<p>If you are reading this, you probably want to customize one or
> > both units. The first step is to copy the unit file of interest
> > from <code>/lib/systemd/system/</code> to
> > <code>/etc/systemd/system/</code>. This will leave the packaged
> > files alone, so that updates don't step on your changes. It also
> > mean you can revert to the packaged files by deleting or moving
> > aside your editions. Then edit the <code>/etc</code> copy.</p>  
> 
> You should not do this.
> The proper way to handle such things is to use
> systemctl edit gpsd.service / gpsd.socket.
> 
> systemctl edit will create an override file, where you can add/change
> the options you want to edit.
> 
> So if the system-wide/packaged file is ammended, you'll still receive
> these changes (unless overwritten before).

Just like the military: there's the right way, the wrong way, and the
systemd way....

OK. I don't see any way to get just the [socket] stanza ready to edit.
So to edit an existing stanza, I should use

systemctl edit --full gpsd.socket

and edit away.


> 
> 
> > +
> > +<p>Then reload systemd:</p>  

Which is now moot because systemctl edit does that for you.


> > +
> > +<p>The next thing to do is modify /etc/default/gpsd to provide the
> > options we want. One to listen on all the interfaces (-G), and
> > don't wait for a client to connect before polling (-n). The
> > GPSD_OPTIONS stanza now looks like:</p>  
> 
> No, you don't want that.
> For usb receivers, create a new udev rules file in /etc/udev/rules.d,
> with a content similar to the one distributed with gpsd:
> 
> ATTRS{idVendor}=="0e8d", ATTRS{idProduct}=="3329", SYMLINK+="gps%n",
> TAG+="systemd", ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
> 
> 
> This will make sure gpsd is configured and de-configured for the
> device when it is being plugged in. Vendorid and product can be
> figured out using lsusb or in /sys/bus/...

Now I'm not following you. Since my GPS receiver is already covered in
60-gpsd.rules and it already has the "gpsdctl@%k.service" and
TAG+="systemd" in it, why do I need another line?


> 
> 
> > +
> > +<pre>
> > +# Other options you want to pass to gpsd
> > +# GPSD_OPTIONS=""
> > +GPSD_OPTIONS="-Gn"
> > +</pre>
> > +
> > +<p>We can kill gpsd. Systemd will restart it for us, this time
> > with the options in place:</p> +
> > +<pre>root@orca:~# kill 12868
> > +root@orca:~# ps aux | grep -i gpsd | grep -v grep ; ls /dev/ttyA*
> > +gpsd     14547  0.5  0.0  18092  3504 ?        S&lt;sl 15:44
> > 0:00 /usr/sbin/gpsd -Gn +/dev/ttyACM0
> > +root@orca:~#</pre>  
> 
> No need for that, see above. Use udev.

????


> 
> 
> > +
> > +<p>But we aren't there yet. gpsd may be listening on all
> > interfaces, but systemd's hold on the socket means it can't hear
> > anything on interfaces other than the loopback. So we copy
> > <code>gpsd.socket</code> from <code>/lib/systemd/system/</code> to
> > <code>/etc/systemd/system/</code>. Then we can edit it. The
> > [Socket] stanza now looks like so:</p> + +<pre> +[Socket]
> > +ListenStream=/var/run/gpsd.sock +ListenStream=[::1]:2947 +#
> > ListenStream=127.0.0.1:2947 +ListenStream=0.0.0.0:2947
> > +SocketMode=0600
> > +</pre>  
> 
> Don't copy it.
> 
> systemctl edit gpsd.socket
> 
> Add
> [Socket]
> ListenStream=
> ListenStream=/var/run/gpsd.sock
> ListenStream=2947
> BindIPv6Only=both
> 
> (untested, basically does:
> - reset config
> - bind to the socket
> - bind to port 2947
> - listen on v6 and v4
> )

Methinks it's simpler to just edit the existing configuration, so I
specified the --full option and got what I wanted, ready to edit. Which
is tested.

Also, your command gives the user an empty file. Which means the user
has to know exactly what he wants in there. That's fine for a systemd
guru. Most gpsd users are not systemd gurus. I'd rather have them edit
the existing configuration and only change what they have to change.

This also saves us a maintenance problem later on. If the stock
gpsd.socket file should change later on, we don't have to remember to
come back to this document and check the sample code here.

Hence the --full option.




-- 
Does anybody read signatures any more?

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

Attachment: troubleshooting.html.2019-10-20.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]