Matthieu
The rules I used for udev are available at: http://www.fridu.org/images/opencpn/70-persistent-usb-gps.rules
I use GPSd for two very different cases. First I have a fixed
station that collect AIS traffic (public port gpsd://fridu.net)
and for this type of usage gpds works seamlessly. My second usage
is dedicated to navigation, and in this case we have more
specifics issues to handles like:
- limited energy capabilities: we need sleep-on-ram to extend
batteries life time (the smaller is your boat, the more your
battery life issue is big)
- accurate positioning can be a matter of life: when you
wakeup-from-ram, you need an accurate positioning in 100% of the
case in less than 10 seconds.
- we often have more than one GPS running: multiplexing two or
more GPS is the best way to make sure at least one is operational
at any time (typically we have two AIS+board)
- crewman are not IT experts: you should not rely on them to
restart a gpsd service in case something goes wrong in the middle
of the night. The only thing they understand it power off/on cycle
with all risks attached to such operation.
etc ...
I installed multiple friend boats with gpsd/opencpn and the only
stable method I found out it to create a fix path for each
USB/serial devices. When running normal gpsd.hotplug script you
can face multiple race conditions, this especially during
sleep/wakeup cycle. The most common issue is the fact that your
GPS pseudo terminal change name, but I also faced situations where
I ended up with two GPSd instances running, or cases where the
udev stop-script runs after udev start-script (look impossible,
but it happens)
I have to confess that I did not make intensive test with the
latest version of gps.hotplug. Nevertheless even current script
rely on many dynamic mechanisms and look very hard to certify as a
"like-critical" feature. I feel more confident to have a fix
instanced of GPSd running on two or more devices 'ex: gpsd
/dev/ttyGPSais /dev/ttyGPSboard' and rely on udev scripts only for
creating device aliases. In case something goes wrong such a
configuration is easier to debug.
Ideally I would love to have on shot configuration script that
would find out plugged GPS devices and would built a set of fix
rules for udev as well as for gpsd. Such a mechanism would
probably be a good compromised in between making non expert life
simple and keep the system easy enough to certify for navigation.
Fulup
Le 28/07/2013 16:11, Matt a écrit :
Salut encore Fulup!
Est-ce que je peut faire un peut de répétition de ma
français avec vous? :-)
Et est-ce que je peut aussi voir vos règles udev pour la
gps, svp?
Les miennes sont trop simples, pas du tout 'correctes',
mais ils marchent pour moi.
Je ne sais pas si c'est possible totalement correct.
Ou, hmmm, est-ce qu'on peut utiliser isgps dans une règle
udev?
It's very unfortunate that only gpsd can tell whether the
device attached to the serial side of the
USB<-->serial adapter is a GPS instead of some other
device, because udev would like to use that information in
rules like your one.
It's a tricky division of labour, isn't it?
I've been thinking about how to make this work 'properly'
recently, but I don't see how yet.
Regards,
Matthieu
-------- Original message --------
From: Fulup Le Foll <address@hidden>
Date:
To: ukyg9e5r6k7gubiekd6 <address@hidden>
Subject: Re: [gpsd-dev] Another release seems called for
Your French is not bad at all :-)
I agree with your analyse, and trace. On my config my problems was
coming from the sleep-onram/wake-up cycle and udev where udev is
the
issue much more than gpsd. I bypass the problem by forcing fixed
name to
my devices in udev rules. It is not perfect because it impose a
manual
config of udev rules, but it works and does not require any
special ACL
for gpsd.
Le 26/07/2013 08:10, ukyg9e5r6k7gubiekd6 a écrit :
> Salut Fulup,
>
> Je ne suis pas sûr que vous avez raison - voir s'il vous
plait mon
> analyse ci-dessous.
> Et maintenant je dois utiliser l'Anglais à cause de mon
mauvais
> Français; pardonnez-mois :-)
>
> Your second point below will only happen if gpsd specifies
the
> O_CREATE flag in an open(s) syscall *or* if it calls the
'creat'
> syscall. See 'man -s 2 open' and/or 'man -s 2 creat'. These
are the
> two ways to create a file under UNIX-like operating systems.
I don't
> know of any other ways to create a file from userspace.
>
> So gpsd should never specify the O_CREAT flag, in order to
avoid
> creating a new useless file named /dev/ttyUSB[0-9]+, which
would
> create the problem you describe.
> As you say, GPSd should never create files in /dev (that is
what udev
> is for).
>
> However, in my testing, if the device specified does not
exist, gpsd
> does not call open(2) on it, nor creat(2). So I think it will
never
> create a new file in the way you describe.
>
> Here are the results I get when I configure gpsd to open the
> nonexistent device '/dev/nonexistent':
>
> address@hidden:~$ sudo strace -f -e open,creat,stat64
/etc/init.d/gpsd
> start 2>&1 | fgrep /dev
> [pid 3881] open("/dev/null",
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE,
> 0666) = 3
> Starting GPS (Global Positioning System) daemon:
gpsdopen("/dev/null",
> O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
> open("/dev/null", O_RDWR) = 4
> stat64("/dev/nonexistent", 0xbfdf41f0) = -1 ENOENT (No such
file or
> directory)
> stat64("/dev/nonexistent", 0xbfdf41f0) = -1 ENOENT (No such
file or
> directory)
> stat64("/dev/ttyS0", {st_mode=S_IFCHR|S_ISVTX|0660,
st_rdev=makedev(4,
> 64), ...}) = 0
>
> You can see that gpsd calls stat on /dev/nonexistent, but
never calls
> open or creat on /dev/nonexistent.
>
> The above results were from a Debian unstable x86 system,
using Debian
> gpsd package version 3.6-5.
> I get similar results from gpsd HEAD compiled from source on
Debian
> x86_64.
>
> Can you please send me 'strace' output like that above, which
shows
> the problem that you are describing, whereby gpsd creates
useless new
> files in /dev?
> I think the behaviour you describe is impossible, but
apparently you
> have seen this happening. This worries me.
>
> If gpsd really does create litter in the user's filesystem
while
> running with root privileges, that would be dangerous, evil,
bad and
> naughty of it. It would be like it breaking into my house and
pissing
> on the furniture :-P We should fix any such serious bug ASAP.
>
> Regards,
>
> Matt
>
> On 25/07/13 08:09, Fulup Le Foll wrote:
>> Gary
>>
>> If udev is able to create /dev/ttyUSB0 once, then it has
enough
>> permission to create it twice.
>>
>> When you unplug a device, a good program like gpsd will
detect the
>> error and try to reopen the same path (ex: /dev/ttyUSB0)
. The "bad"
>> news: If the path does point to an existing file/device
with an open
>> syscall Linux will try to create the missing file.
>>
>> As a result when a program running under "dialout" group
try to open
>> /dev/ttyUSB0
>>
>> * if /dev/ttyUSB0 already exist, then the open call
succeeds
>> * if /dev/ttyUSB0 does not exist. You get a permission
error because
>> "dialout" is not enough to create the missing file in
/dev. Worse
>> if you had enough right to create an empty file in
/dev, then
>> 'udev' would move to next available name and would
create
>> /dev/ttyUSB1
>>
>> Fulup
>>
>>
>> Le 24/07/2013 21:56, Gary E. Miller a écrit :
>>> Yo Fulup!
>>>
>>> On Wed, 24 Jul 2013 21:37:12 +0200
>>> Fulup Le Foll<address@hidden>
wrote:
>>>
>>>> Naming of device is not a question of timeout but
a question of
>>>> availability of the path.
>>> Potentially, but not in my case. I always have
ttyUSB0. My case is a
>>> permission problem.
>>>
>>> RGDS
>>> GARY
>>>
---------------------------------------------------------------------------
>>>
>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite
E, Bend, OR 97701
>>> address@hidden
Tel:+1(541)382-8588
>>
>>
>> --
>> Tel: 0972.235.723
>> Mail:address@hidden
>> http://www.sinagot.net
>
--
Tel: 0972.235.723
Mail: address@hidden
http://www.sinagot.net
--
Tel: 0972.235.723
Mail: address@hidden
http://www.sinagot.net
|