gpsd-users
[Top][All Lists]
Advanced

[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



reply via email to

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