[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] gpsd and cold plugging
From: |
Miroslav Lichvar |
Subject: |
Re: [gpsd-users] gpsd and cold plugging |
Date: |
Tue, 22 Apr 2014 11:27:40 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Mar 18, 2014 at 10:30:39PM +0100, Bjørn Forsman wrote:
> When the system starts after power-on, the hot (cold?) plug event for
> the GPS arrives before systemd has started listening on the gpsd
> sockets. That means gpsdctl (invoked by the gpsd udev rules) thinks it
> needs to spawn a gpsd instance. But according to systemd / udev
> documentation[udev], spawning long-running daemons from udev RUN+=
> directives is not OK:
I guess you already found an answer elsewhere, but I thought I'd post
what I did in the Fedora package to fix this problem. The only
solution I found that works reliably with both cold and hot plug was
to create a service template for gpsdctl and modify the udev rules to
set ENV{SYSTEMD_WANTS}="address@hidden" instead of running gpsdctl
directly from udev.
Here is the gpsdctl service:
http://pkgs.fedoraproject.org/cgit/gpsd.git/plain/gpsdctl.service
> I was thinking that the solution to this race between cold plug events
> and systemd socket listening must simply be to let gpsd do an initial
> scan of GPSs itself, when it starts. And stop gpsdctl from ever
> spawning gpsd, because systemd already has that covered (socket based
> activation).
How would gpsd know which serial devices it should try to open? It
would have to have some configuration file with a list of IDS, which
are now in the udev file.
> Having gpsd do the scan itself would also make restarting
> it Just Work, unlike the current situation where I have to re-plug my
> GPS after restarting gpsd.
Yeah, that would be nice. You can trigger an udev event manually with
"udevadm trigger --sysname-match=ttyUSB0 --action add", but something
that would add automatically all devices controlled by the previous
gpsd instance would be a nice improvement.
--
Miroslav Lichvar