Unplugging USB gps receivers - gpsd behaviour.

[Two Sank]

When I plug in my BU-353 GPS receiver into Ubuntu Jaunty netbook remix
on my Eee PC 900 it creates ttyUSB0 and launches gpsd (2.38) which then
delivers fixes to my application (JOSM).

When I unplug the receiver, there is no "remove" event generated so that
/lib/udev/gpsd.hotplug.wrapper is not invoked with a "remove" event.

The next time I plug the receiver in it creates ttyUSB1. Then
subsequently ttyUSB2, ttyUSB3 and ttyUSB4. However, then the
characteristics change and when I unplug it after ttyUSB4 it DOES give
an unplug event from UDEV, calls the remove action
/lib/udev/gpsd.hotplug.wrapper and removes ttyUSB4 from /dev.
Subsequent plugging in always attaches to ttyUSB4 giving both add and
remove events.

If I kill gpsd daemon after the first creation of ttyUSB0, then the
remove event IS generated and /lib/udev/gpsd.hotplug.wrapper is invoked,
but of course it complains then that it cannot locate gpsd (not
unexpectedly).

My question: Is this the anticipated behaviour of gpsd? If not, can
anybody suggest what might be wrong?
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

Two Sank wrote:

> When I plug in my BU-353 GPS receiver into Ubuntu Jaunty netbook remix
> on my Eee PC 900 it creates ttyUSB0 and launches gpsd (2.38) which then
> delivers fixes to my application (JOSM).
>
> When I unplug the receiver, there is no "remove" event generated so that
> /lib/udev/gpsd.hotplug.wrapper is not invoked with a "remove" event.
>
> The next time I plug the receiver in it creates ttyUSB1. Then
> subsequently ttyUSB2, ttyUSB3 and ttyUSB4. However, then the
> characteristics change and when I unplug it after ttyUSB4 it DOES give
> an unplug event from UDEV, calls the remove action
> /lib/udev/gpsd.hotplug.wrapper and removes ttyUSB4 from /dev.
> Subsequent plugging in always attaches to ttyUSB4 giving both add and
> remove events.
>
>  

On my machine (gentoo), using a fairly recent udev (141 from memory) I
observe that the gentoo supplied hotplug script (apparently different to
the gpsd supplied hotplug script) does not generate remove events
because the udev remove event matching appears not to match the same
features that the "add" event does.  In the end I couldn't do any better
than calling remove on all TTY com port remove events...

I don't have the details in front of me, but it may be worth watching
the debug through the udev monitor script and twiddle with your remove
rules until you figure out what isn't matching?

Good luck

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>> When I plug in my BU-353 GPS receiver into Ubuntu Jaunty netbook remix
>> on my Eee PC 900 it creates ttyUSB0 and launches gpsd (2.38) which then
>> delivers fixes to my application (JOSM).
>>
>> When I unplug the receiver, there is no "remove" event generated so that
>> /lib/udev/gpsd.hotplug.wrapper is not invoked with a "remove" event.
>>
>> The next time I plug the receiver in it creates ttyUSB1. Then
>> subsequently ttyUSB2, ttyUSB3 and ttyUSB4. However, then the
>> characteristics change and when I unplug it after ttyUSB4 it DOES give
>> an unplug event from UDEV, calls the remove action
>> /lib/udev/gpsd.hotplug.wrapper and removes ttyUSB4 from /dev.
>> Subsequent plugging in always attaches to ttyUSB4 giving both add and
>> remove events.
>>
>>  
>
> On my machine (gentoo), using a fairly recent udev (141 from memory) I
> observe that the gentoo supplied hotplug script (apparently different to
> the gpsd supplied hotplug script) does not generate remove events
> because the udev remove event matching appears not to match the same
> features that the "add" event does.  In the end I couldn't do any better
> than calling remove on all TTY com port remove events...
>
> I don't have the details in front of me, but it may be worth watching
> the debug through the udev monitor script and twiddle with your remove
> rules until you figure out what isn't matching?
>

Hi Ed, thanks for responding.
The truth is that I cannot find ANY remove event for the first 4 tty
devices. After that the remove event is invoked and works just fine.
Also, if I kill gpsd, then the remove event is generated and the remove
script for gpsd is called - but gpsd is of course missing.  I am really
puzzled. I can only think that because gpsd is keeping the tty open,
Ubuntu does not generate the receive event - but why???

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

Two Sank wrote:
>
> Hi Ed, thanks for responding.
> The truth is that I cannot find ANY remove event for the first 4 tty
> devices. After that the remove event is invoked and works just fine.
> Also, if I kill gpsd, then the remove event is generated and the remove
> script for gpsd is called - but gpsd is of course missing.  I am really
> puzzled. I can only think that because gpsd is keeping the tty open,
> Ubuntu does not generate the receive event - but why???
>  

If you need help then why are you ignoring all the help I tried to offer?

Please use udev monitor and check the exact events.  Then simplify your
remove event until it starts to fire - this will show a lot of info
about why it's not firing. In my case I need a udev rule which is simply
matched on any ttyUSB event, no matter what driver...

Ed W
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>>
>> Hi Ed, thanks for responding.
>> The truth is that I cannot find ANY remove event for the first 4 tty
>> devices. After that the remove event is invoked and works just fine.
>> Also, if I kill gpsd, then the remove event is generated and the remove
>> script for gpsd is called - but gpsd is of course missing.  I am really
>> puzzled. I can only think that because gpsd is keeping the tty open,
>> Ubuntu does not generate the receive event - but why???
>>  
>
> If you need help then why are you ignoring all the help I tried to offer?
>
> Please use udev monitor and check the exact events.  Then simplify your
> remove event until it starts to fire - this will show a lot of info
> about why it's not firing. In my case I need a udev rule which is simply
> matched on any ttyUSB event, no matter what driver...
>
> Ed W
>

Sorry ed, been on holiday and only on email when I can connect. I will
be home tonight so I will start working again.

I have found out why ttyUSB4 works - the receiver is never attached to
it! The receiver stops being attached after ttyUSB3. I have logged the
UDEV trace using udevadm but i don't understand it all yet. I have found
some guidance and have been reading up on udev rules so I can understand
what you write. I am certain you are right, there is a udev rule problem
somewhere. I can see the kernel "remove" events but cannot yet figure
out where they go. More later, please don't give up on me!
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>> When I plug in my BU-353 GPS receiver into Ubuntu Jaunty netbook remix
>> on my Eee PC 900 it creates ttyUSB0 and launches gpsd (2.38) which then
>> delivers fixes to my application (JOSM).
>>
>> When I unplug the receiver, there is no "remove" event generated so that
>> /lib/udev/gpsd.hotplug.wrapper is not invoked with a "remove" event.
>>
>> The next time I plug the receiver in it creates ttyUSB1. Then
>> subsequently ttyUSB2, ttyUSB3 and ttyUSB4. However, then the
>> characteristics change and when I unplug it after ttyUSB4 it DOES give
>> an unplug event from UDEV, calls the remove action
>> /lib/udev/gpsd.hotplug.wrapper and removes ttyUSB4 from /dev.
>> Subsequent plugging in always attaches to ttyUSB4 giving both add and
>> remove events.
>>
>>  
>
> On my machine (gentoo), using a fairly recent udev (141 from memory) I
> observe that the gentoo supplied hotplug script (apparently different to
> the gpsd supplied hotplug script) does not generate remove events
> because the udev remove event matching appears not to match the same
> features that the "add" event does.  In the end I couldn't do any better
> than calling remove on all TTY com port remove events...
>
> I don't have the details in front of me, but it may be worth watching
> the debug through the udev monitor script and twiddle with your remove
> rules until you figure out what isn't matching?
>

OK, Ed, I have now logged some Kernel and UDEV rules. First can you tell
me if I am doing the right thing. I did:
sudo udevadm monitor

That gave me a lot of events with Kernel and UDEV at the beginning of
each line. What I have not yet managed to understand is exactly which
UDEV rule is actually firing on which event. There seems to be no
indication in the log as to which rule in which file is causing
anything. I can see the rules in /lib/rules.d/40-gpsd.rules

BUT what is interesting in the logs of the "add" event there are lots of
references to "tty". In the "remove" event, there is not a single
reference to the letters "tty" in either the kernel or the UDEV events.
Since the /lib/rules.d/40-gpsd.rules has a rule which says
SUBSYSTEM!="tty", GOTO="gpsd_rules_end" i.e. do nothing if it is not a
tty, I suspect that there are NO tty rules being fired on the remove
event hence the gpsd rules are not even being tried.

All I can think of doing is searching all the rules to try to figure out
why the 2303 device is being recognised as a tty device on add, but not
on remove.  Let me know if you are interested in the event logs and I
will post them on a website (a bit big for here).
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>>
>> Hi Ed, thanks for responding.
>> The truth is that I cannot find ANY remove event for the first 4 tty
>> devices. After that the remove event is invoked and works just fine.
>> Also, if I kill gpsd, then the remove event is generated and the remove
>> script for gpsd is called - but gpsd is of course missing.  I am really
>> puzzled. I can only think that because gpsd is keeping the tty open,
>> Ubuntu does not generate the receive event - but why???
>>  
>
> If you need help then why are you ignoring all the help I tried to offer?
>
> Please use udev monitor and check the exact events.  Then simplify your
> remove event until it starts to fire - this will show a lot of info
> about why it's not firing. In my case I need a udev rule which is simply
> matched on any ttyUSB event, no matter what driver...

Ed, I failed to mention that the original "remove" rule is:

ACTION="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"

the only thing that bypasses that rule is: if the subsystem is not tty
all the gpsd rules are ignored including this one. I think that the
above rule is about as simple as possible.
So I have to figure out why some other rule does not think that the
receiver is a tty device. I don't like the idea of triggering the remove
for all possible subsystems e.g. when I remove a USB DVD drive.

What I think I have to do is find out what rules are being fired for the
device and, as you wrote, find out why the add rules identify the device
as tty but the remove rules do not.  I can do that once I can figure out
from the logs which UDEV rules are actually being triggered for "add"
since there seems to be quite a lot of them in the directory.
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>> When I plug in my BU-353 GPS receiver into Ubuntu Jaunty netbook remix
>> on my Eee PC 900 it creates ttyUSB0 and launches gpsd (2.38) which then
>> delivers fixes to my application (JOSM).
>>
>> When I unplug the receiver, there is no "remove" event generated so that
>> /lib/udev/gpsd.hotplug.wrapper is not invoked with a "remove" event.
>>
>> The next time I plug the receiver in it creates ttyUSB1. Then
>> subsequently ttyUSB2, ttyUSB3 and ttyUSB4. However, then the
>> characteristics change and when I unplug it after ttyUSB4 it DOES give
>> an unplug event from UDEV, calls the remove action
>> /lib/udev/gpsd.hotplug.wrapper and removes ttyUSB4 from /dev.
>> Subsequent plugging in always attaches to ttyUSB4 giving both add and
>> remove events.
>>
>>  
>
> On my machine (gentoo), using a fairly recent udev (141 from memory) I
> observe that the gentoo supplied hotplug script (apparently different to
> the gpsd supplied hotplug script) does not generate remove events
> because the udev remove event matching appears not to match the same
> features that the "add" event does.  In the end I couldn't do any better
> than calling remove on all TTY com port remove events...
>
> I don't have the details in front of me, but it may be worth watching
> the debug through the udev monitor script and twiddle with your remove
> rules until you figure out what isn't matching?
>

Ed, an update on this. Other people have found a similar problem viz:
http://www.linuxquestions.org/questions/programming-9/udev-not-called-to-remove-open-usb-serial-device-585603/
Essentially the kernel does not create a Kernel event for removing an
open serial device. It also looks like it fails to alert the driver and
the application that the device has vanished.

Looking at
http://lkml.indiana.edu/hypermail/linux/kernel/0907.2/01845.html it
would appear to be a bug in the kernel being worked on as recently as
July 09. Follow that thread by Alan Stern and Alan Cox which implies
that the solution is not going to be easy. The problem also has kernel
reliability impacts (though not for my case).
Now, I am not familiar with writing UDEV rules, but I am even less
familiar with patching the Linux kernel so going down that route is not
an option for me. What I might try to do (at least temporarily) is to
fire a rule based on the USB remove event which IS fired (as opposed to
a tty event which is not) just for my particular device.

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

>> Two Sank wrote:
>>> Hi Ed, thanks for responding.
>>> The truth is that I cannot find ANY remove event for the first 4 tty
>>> devices. After that the remove event is invoked and works just fine.
>>> Also, if I kill gpsd, then the remove event is generated and the remove
>>> script for gpsd is called - but gpsd is of course missing.  I am really
>>> puzzled. I can only think that because gpsd is keeping the tty open,
>>> Ubuntu does not generate the receive event - but why???
>>>  
>> If you need help then why are you ignoring all the help I tried to offer?
>>
>> Please use udev monitor and check the exact events.  Then simplify your
>> remove event until it starts to fire - this will show a lot of info
>> about why it's not firing. In my case I need a udev rule which is simply
>> matched on any ttyUSB event, no matter what driver...
>
> Ed, I failed to mention that the original "remove" rule is:
>
> ACTION="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
>
> the only thing that bypasses that rule is: if the subsystem is not tty
> all the gpsd rules are ignored including this one. I think that the
> above rule is about as simple as possible.
> So I have to figure out why some other rule does not think that the
> receiver is a tty device. I don't like the idea of triggering the remove
> for all possible subsystems e.g. when I remove a USB DVD drive.
>
> What I think I have to do is find out what rules are being fired for the
> device and, as you wrote, find out why the add rules identify the device
> as tty but the remove rules do not.  I can do that once I can figure out
> from the logs which UDEV rules are actually being triggered for "add"
> since there seems to be quite a lot of them in the directory.

Warren Free pointed out that I had made an error above. The original "remove" rule was:
ACTION=="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
== not =

However, I now have further information. I am coming to believe that the problem
of the /dev/ttyUSBx not vanishing may well be unsolvable without either totally killing
the gpsd daemon or the behaviour of the Linux kernel tty subsystem being fixed.
I fixed the UDEV rules so that the remove script is called, albeit with a device name not
of the form /dev/ttyUSBx
First I suspected that the name given caused the problem, but a few debug statements
showed that gpsd was being sent the close command for "remove". For anyone interested the
log below shows that, even with the gpsd NOT holding open /dev/ttyUSB0, it still does
not vanish on unplug. Only killing the daemon seems to do that. The log below is
commented with the actions I took. If anyone can see a flaw with the logic, I would
be very interested. The lines beginning $ are the commands, the rest the responses.

$ #This is test with fix applied so that "remove" is called.
$ #The machine has just been rebooted and the receiver is not plugged in.
$ #first look at ttyUSB devices
$ ls /dev/ttyU*
ls: cannot access /dev/ttyU*: No such file or directory
$ #none. Now plug in the receiver and test to see if gpsd is running
$ ls /dev/ttyU*
/dev/ttyUSB0
$ ps ax|grep gps
 3385 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
 3392 pts/0    S+     0:00 grep gps
$ #OK, ttyUSB0 is there and gpsd is running. Next check if it is open.
$ sudo fuser /dev/ttyUSB0
/dev/ttyUSB0:         3385
$ #Yes, gpsd has the device open. Here I unplug and look at state
$ ls /dev/ttyU*
/dev/ttyUSB0
$ #ttyUSB0 is still there, test gpsd existing and having it open
$ ps ax|grep gps
 3385 ?        S<sl   0:01 gpsd -F /var/run/gpsd.sock
$ sudo fuser /dev/ttyUSB0
$ #no output from fuser so /dev/ttyUSB0 seems to be there and NOT open.
$ #next, kill the daemon and see if /dev/ttyUSB0 is still there
$ sudo kill -9 3385
$ ls /dev/ttyU*
ls: cannot access /dev/ttyU*: No such file or directory
$ #now it has gone. Perhaps it is a question of timing of closing because
$ #the script is forked. So here I plug in again and tell gpsd to
$ #close manually before unplugging the receiver.
$ ls /dev/ttyU*
/dev/ttyUSB0
$ ps ax|grep gps
 3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
$ sudo fuser /dev/ttyUSB0
/dev/ttyUSB0:         3637
$ #yes, /dev/ttyUSB0 is back, gpsd is running and has it open.
$ #call the gpsd remove script by hand before unplugging.
$ sudo /lib/udev/gpsd.hotplug remove /dev/ttyUSB0
$ sudo fuser /dev/ttyUSB0
$ #No output, therefore gpsd has definitely closed the connection
$ ps ax|grep gps
 3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
$ #but gpsd is still running. Here I unplug and see if ttyUSB0 goes
$ ps ax|grep gps
 3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
$ ls /dev/ttyU*
/dev/ttyUSB0
$ #no, /dev/ttyUSB0 is still present.
$ sudo fuser /dev/ttyUSB0
$ #Empty response so nothing has it open.
$ #So telling gpsd to disconnect is insufficient - apart from kill -9 what is sufficient?

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Bob Cunningham-4]

On 10/18/2009 11:39 AM, Two Sank wrote:

>>> Two Sank wrote:
>>>        
>>>> Hi Ed, thanks for responding.
>>>> The truth is that I cannot find ANY remove event for the first 4 tty
>>>> devices. After that the remove event is invoked and works just fine.
>>>> Also, if I kill gpsd, then the remove event is generated and the remove
>>>> script for gpsd is called - but gpsd is of course missing.  I am really
>>>> puzzled. I can only think that because gpsd is keeping the tty open,
>>>> Ubuntu does not generate the receive event - but why???
>>>>
>>>>          
>>> If you need help then why are you ignoring all the help I tried to offer?
>>>
>>> Please use udev monitor and check the exact events.  Then simplify your
>>> remove event until it starts to fire - this will show a lot of info
>>> about why it's not firing. In my case I need a udev rule which is simply
>>> matched on any ttyUSB event, no matter what driver...
>>>        
>> Ed, I failed to mention that the original "remove" rule is:
>>
>> ACTION="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
>>
>> the only thing that bypasses that rule is: if the subsystem is not tty
>> all the gpsd rules are ignored including this one. I think that the
>> above rule is about as simple as possible.
>> So I have to figure out why some other rule does not think that the
>> receiver is a tty device. I don't like the idea of triggering the remove
>> for all possible subsystems e.g. when I remove a USB DVD drive.
>>
>> What I think I have to do is find out what rules are being fired for the
>> device and, as you wrote, find out why the add rules identify the device
>> as tty but the remove rules do not.  I can do that once I can figure out
>> from the logs which UDEV rules are actually being triggered for "add"
>> since there seems to be quite a lot of them in the directory.
>>      
> Warren Free pointed out that I had made an error above. The original "remove" rule was:
> ACTION=="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
> == not =
>
> However, I now have further information. I am coming to believe that the problem
> of the /dev/ttyUSBx not vanishing may well be unsolvable without either totally killing
> the gpsd daemon or the behaviour of the Linux kernel tty subsystem being fixed.
> I fixed the UDEV rules so that the remove script is called, albeit with a device name not
> of the form /dev/ttyUSBx
> First I suspected that the name given caused the problem, but a few debug statements
> showed that gpsd was being sent the close command for "remove". For anyone interested the
> log below shows that, even with the gpsd NOT holding open /dev/ttyUSB0, it still does
> not vanish on unplug. Only killing the daemon seems to do that. The log below is
> commented with the actions I took. If anyone can see a flaw with the logic, I would
> be very interested. The lines beginning $ are the commands, the rest the responses.
>
> $ #This is test with fix applied so that "remove" is called.
> $ #The machine has just been rebooted and the receiver is not plugged in.
> $ #first look at ttyUSB devices
> $ ls /dev/ttyU*
> ls: cannot access /dev/ttyU*: No such file or directory
> $ #none. Now plug in the receiver and test to see if gpsd is running
> $ ls /dev/ttyU*
> /dev/ttyUSB0
> $ ps ax|grep gps
>   3385 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
>   3392 pts/0    S+     0:00 grep gps
> $ #OK, ttyUSB0 is there and gpsd is running. Next check if it is open.
> $ sudo fuser /dev/ttyUSB0
> /dev/ttyUSB0:         3385
> $ #Yes, gpsd has the device open. Here I unplug and look at state
> $ ls /dev/ttyU*
> /dev/ttyUSB0
> $ #ttyUSB0 is still there, test gpsd existing and having it open
> $ ps ax|grep gps
>   3385 ?        S<sl   0:01 gpsd -F /var/run/gpsd.sock
> $ sudo fuser /dev/ttyUSB0
> $ #no output from fuser so /dev/ttyUSB0 seems to be there and NOT open.
> $ #next, kill the daemon and see if /dev/ttyUSB0 is still there
> $ sudo kill -9 3385
> $ ls /dev/ttyU*
> ls: cannot access /dev/ttyU*: No such file or directory
> $ #now it has gone. Perhaps it is a question of timing of closing because
> $ #the script is forked. So here I plug in again and tell gpsd to
> $ #close manually before unplugging the receiver.
> $ ls /dev/ttyU*
> /dev/ttyUSB0
> $ ps ax|grep gps
>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
> $ sudo fuser /dev/ttyUSB0
> /dev/ttyUSB0:         3637
> $ #yes, /dev/ttyUSB0 is back, gpsd is running and has it open.
> $ #call the gpsd remove script by hand before unplugging.
> $ sudo /lib/udev/gpsd.hotplug remove /dev/ttyUSB0
> $ sudo fuser /dev/ttyUSB0
> $ #No output, therefore gpsd has definitely closed the connection
> $ ps ax|grep gps
>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
> $ #but gpsd is still running. Here I unplug and see if ttyUSB0 goes
> $ ps ax|grep gps
>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
> $ ls /dev/ttyU*
> /dev/ttyUSB0
> $ #no, /dev/ttyUSB0 is still present.
> $ sudo fuser /dev/ttyUSB0
> $ #Empty response so nothing has it open.
> $ #So telling gpsd to disconnect is insufficient - apart from kill -9 what is sufficient?
>    

Sorry to intrude, since I'm not sure if this is germane to the thread,
but I also had an issue with gpsd holding on to devices it wasn't
using.  But my case was bizarre: fuser showed gpsd was occupying
/dev/parport0, the parallel port!  Killing gpsd released parport0, which
I was using to control external hardware.

Bizarre.  I had mentioned it on this list when it first happened, but
the response (primarily disbelief) was nothing I could make use of,
despite many strace runs.

Fortunately, my GPS USB-serial interface (FTDI) had a 2K buffer, so my
"solution" was to add a wrapper around my parallel port twiddling to do
the following: Wait for the serial port to become idle (avoid
interrupting a sentence), close the gpsd connection, kill gpsd, twiddle
the parallel port, restart gpsd, then reopen the gpsd connection.  This
was easily done fast enough to avoid GPS data loss.

It's a hack of the ugliest kind, but something similar may prove useful
as part of a temporary solution for your problem.  In my case, it worked
because one process managed both the gpsd connection and the parallel port.

In your case, you may want gpsd to be spawned/killed whenever your
device is connected/removed.  Which means starting a gpsd instance for
each USB-serial device when it appears, which in turn means that gpsd
instances that do not find a GPS on a given USB serial port would need
to be killed.

For this, it would be useful if gpsd had an option that would permit it
to "Attempt GPS discovery, then exit if no GPS found."  The equivalent
can certainly be done manually by having the connect script start gpsd,
sleep, attempt a connection, then kill gpsd if no connection is found.

A veritable stack o' hacks, but it may work until a better solution is
found.

Perhaps the gpsd command-line options  '-b', '-n', '-N', the gpsd
protocol commands  'b', 'f', 'g', 'k', 'n', and SIGHUP could also prove
useful.

HTH,

-BobC

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

Two Sank wrote:

> OK, Ed, I have now logged some Kernel and UDEV rules. First can you tell
> me if I am doing the right thing. I did:
> sudo udevadm monitor
>
> That gave me a lot of events with Kernel and UDEV at the beginning of
> each line. What I have not yet managed to understand is exactly which
> UDEV rule is actually firing on which event. There seems to be no
> indication in the log as to which rule in which file is causing
> anything. I can see the rules in /lib/rules.d/40-gpsd.rules
>
> BUT what is interesting in the logs of the "add" event there are lots of
> references to "tty". In the "remove" event, there is not a single
> reference to the letters "tty" in either the kernel or the UDEV events.
> Since the /lib/rules.d/40-gpsd.rules has a rule which says
> SUBSYSTEM!="tty", GOTO="gpsd_rules_end" i.e. do nothing if it is not a
> tty, I suspect that there are NO tty rules being fired on the remove
> event hence the gpsd rules are not even being tried.
>  

Correct - from memory my rule with udev-141 needed to be something like:

KERNEL=="ttyUSB[0-9]*" RUN=etc

Anything more exact than that would not match.  Actually I *think* I
couldn't even match the tty subsystem (not at the machine to test)

Additionally as you have presumably discovered, the choice of kernel is
important because certain kernels around the 2.6.29/30 ish time frame
exhibit a similar bug to what you describe? I think I moved to 2.6.30.6
- I don't have it running at present, but I believe that I probably
picked that because it was working ok...

You could also try varying the udev version you are using?  I'm on
gentoo here so that's quite easy to do, but perhaps your distro has a
variety of options available...? Consider raising this particular issue
further on the udev/kernel list, but be sure to simplify your problem to
a simple script which just prints hello to a log file or similar...
(this is the simplest way to debug things)

Oh, additionally note that the gpsd supplied udev script causes udev to
hang indefinitely on a subset of udev versions - the gentoo init script
is modified to run the gpsd bits in a separately forked thread.  It
appears to make no difference on the version that I am using, but it's
worth noting this potentially problem isn't biting you?  Debug it by
disabling the ADD part of the rules, run the script manually from the
command line and then debug the remove events only..?

Good luck

Ed W






_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Ed W wrote:

> Two Sank wrote:
>> OK, Ed, I have now logged some Kernel and UDEV rules. First can you tell
>> me if I am doing the right thing. I did:
>> sudo udevadm monitor
>>
>> That gave me a lot of events with Kernel and UDEV at the beginning of
>> each line. What I have not yet managed to understand is exactly which
>> UDEV rule is actually firing on which event. There seems to be no
>> indication in the log as to which rule in which file is causing
>> anything. I can see the rules in /lib/rules.d/40-gpsd.rules
>>
>> BUT what is interesting in the logs of the "add" event there are lots of
>> references to "tty". In the "remove" event, there is not a single
>> reference to the letters "tty" in either the kernel or the UDEV events.
>> Since the /lib/rules.d/40-gpsd.rules has a rule which says
>> SUBSYSTEM!="tty", GOTO="gpsd_rules_end" i.e. do nothing if it is not a
>> tty, I suspect that there are NO tty rules being fired on the remove
>> event hence the gpsd rules are not even being tried.
>>  
>
> Correct - from memory my rule with udev-141 needed to be something like:
>
> KERNEL=="ttyUSB[0-9]*" RUN=etc

Ed, I checked very carefully, there are NO kernel "remove" events containing the
string "tty".  There are a few containing various "USB" keys which I have used
to trigger the remove of gpsd.
>
> Anything more exact than that would not match.  Actually I *think* I
> couldn't even match the tty subsystem (not at the machine to test)
>
> Additionally as you have presumably discovered, the choice of kernel is
> important because certain kernels around the 2.6.29/30 ish time frame
> exhibit a similar bug to what you describe? I think I moved to 2.6.30.6
> - I don't have it running at present, but I believe that I probably
> picked that because it was working ok...

OK, now you are getting beyond my capabilities. I have NO idea how good an
idea it is to replace a kernel in a particular distribution of Ubuntu.
You are correct, I am running on an older kernel that you. Jaunty in the
netbook remix flavour reports its kernel as "Ubuntu 2.6.28-15-generic".
I have NO idea even how to rebuild that, never having built a kernel.
I am not sure my little netbook is the right place to build one either.
Presumeably there is a good chance that I would break something else?
Also, the next version of Ubuntu is due out before too long so I might
just wait for that.
>
> You could also try varying the udev version you are using?  I'm on
> gentoo here so that's quite easy to do, but perhaps your distro has a
> variety of options available...? Consider raising this particular issue
> further on the udev/kernel list, but be sure to simplify your problem to
> a simple script which just prints hello to a log file or similar...
> (this is the simplest way to debug things)
UDEV seems to be working just fine. I am pretty sure that it is the
kernel which is not working correctly. You will see from an earlier post
that I discovered a thread on the lists associated with the kernel about
the lack of remove events for tty that are held open (not just ttyUSB).
In one case (not mine) this was causing a kernel crash.
They were working on this in July of this year so perhaps that is now fixed.
Once I put in the rule to trigger on an existing kernel event, the remove
action was called correctly.
>
> Oh, additionally note that the gpsd supplied udev script causes udev to
> hang indefinitely on a subset of udev versions - the gentoo init script
> is modified to run the gpsd bits in a separately forked thread.  It
> appears to make no difference on the version that I am using, but it's
> worth noting this potentially problem isn't biting you?  Debug it by
> disabling the ADD part of the rules, run the script manually from the
> command line and then debug the remove events only..?
I can see from the script that there was a problem.
All of the script is now run on a separate thread.
There was a deadlock condition. This seems to have been fixed in the
version I am using which now does a fork.
However, I did suspect that forking to another process was
the cause of the problem - I wondered if the delayed release of the ttyUSB
was the cause of it not vanishing. My last test (calling the release by hand)
showed that it did not matter how early the release was called, the ttyUSBx was
not being removed, despite no processes keeping it open and no device being
attached to it. What I intend to do is to try to write up these experiments
and results on a website to make them more understandable than this thread.
Thanks for all your help.

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Two Sank]

Bob Cunningham wrote:

> On 10/18/2009 11:39 AM, Two Sank wrote:
>>>> Two Sank wrote:
>>>>      
>>>>> Hi Ed, thanks for responding.
>>>>> The truth is that I cannot find ANY remove event for the first 4 tty
>>>>> devices. After that the remove event is invoked and works just fine.
>>>>> Also, if I kill gpsd, then the remove event is generated and the
>>>>> remove
>>>>> script for gpsd is called - but gpsd is of course missing.  I am
>>>>> really
>>>>> puzzled. I can only think that because gpsd is keeping the tty open,
>>>>> Ubuntu does not generate the receive event - but why???
>>>>>
>>>>>          
>>>> If you need help then why are you ignoring all the help I tried to
>>>> offer?
>>>>
>>>> Please use udev monitor and check the exact events.  Then simplify your
>>>> remove event until it starts to fire - this will show a lot of info
>>>> about why it's not firing. In my case I need a udev rule which is
>>>> simply
>>>> matched on any ttyUSB event, no matter what driver...
>>>>        
>>> Ed, I failed to mention that the original "remove" rule is:
>>>
>>> ACTION="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
>>>
>>> the only thing that bypasses that rule is: if the subsystem is not tty
>>> all the gpsd rules are ignored including this one. I think that the
>>> above rule is about as simple as possible.
>>> So I have to figure out why some other rule does not think that the
>>> receiver is a tty device. I don't like the idea of triggering the remove
>>> for all possible subsystems e.g. when I remove a USB DVD drive.
>>>
>>> What I think I have to do is find out what rules are being fired for the
>>> device and, as you wrote, find out why the add rules identify the device
>>> as tty but the remove rules do not.  I can do that once I can figure out
>>> from the logs which UDEV rules are actually being triggered for "add"
>>> since there seems to be quite a lot of them in the directory.
>>>      
>> Warren Free pointed out that I had made an error above. The original
>> "remove" rule was:
>> ACTION=="remove", RUN+="/lib/udev/gpsd.hotplug.wrapper"
>> == not =
>>
>> However, I now have further information. I am coming to believe that
>> the problem
>> of the /dev/ttyUSBx not vanishing may well be unsolvable without
>> either totally killing
>> the gpsd daemon or the behaviour of the Linux kernel tty subsystem
>> being fixed.
>> I fixed the UDEV rules so that the remove script is called, albeit
>> with a device name not
>> of the form /dev/ttyUSBx
>> First I suspected that the name given caused the problem, but a few
>> debug statements
>> showed that gpsd was being sent the close command for "remove". For
>> anyone interested the
>> log below shows that, even with the gpsd NOT holding open
>> /dev/ttyUSB0, it still does
>> not vanish on unplug. Only killing the daemon seems to do that. The
>> log below is
>> commented with the actions I took. If anyone can see a flaw with the
>> logic, I would
>> be very interested. The lines beginning $ are the commands, the rest
>> the responses.
>>
>> $ #This is test with fix applied so that "remove" is called.
>> $ #The machine has just been rebooted and the receiver is not plugged in.
>> $ #first look at ttyUSB devices
>> $ ls /dev/ttyU*
>> ls: cannot access /dev/ttyU*: No such file or directory
>> $ #none. Now plug in the receiver and test to see if gpsd is running
>> $ ls /dev/ttyU*
>> /dev/ttyUSB0
>> $ ps ax|grep gps
>>   3385 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
>>   3392 pts/0    S+     0:00 grep gps
>> $ #OK, ttyUSB0 is there and gpsd is running. Next check if it is open.
>> $ sudo fuser /dev/ttyUSB0
>> /dev/ttyUSB0:         3385
>> $ #Yes, gpsd has the device open. Here I unplug and look at state
>> $ ls /dev/ttyU*
>> /dev/ttyUSB0
>> $ #ttyUSB0 is still there, test gpsd existing and having it open
>> $ ps ax|grep gps
>>   3385 ?        S<sl   0:01 gpsd -F /var/run/gpsd.sock
>> $ sudo fuser /dev/ttyUSB0
>> $ #no output from fuser so /dev/ttyUSB0 seems to be there and NOT open.
>> $ #next, kill the daemon and see if /dev/ttyUSB0 is still there
>> $ sudo kill -9 3385
>> $ ls /dev/ttyU*
>> ls: cannot access /dev/ttyU*: No such file or directory
>> $ #now it has gone. Perhaps it is a question of timing of closing because
>> $ #the script is forked. So here I plug in again and tell gpsd to
>> $ #close manually before unplugging the receiver.
>> $ ls /dev/ttyU*
>> /dev/ttyUSB0
>> $ ps ax|grep gps
>>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
>> $ sudo fuser /dev/ttyUSB0
>> /dev/ttyUSB0:         3637
>> $ #yes, /dev/ttyUSB0 is back, gpsd is running and has it open.
>> $ #call the gpsd remove script by hand before unplugging.
>> $ sudo /lib/udev/gpsd.hotplug remove /dev/ttyUSB0
>> $ sudo fuser /dev/ttyUSB0
>> $ #No output, therefore gpsd has definitely closed the connection
>> $ ps ax|grep gps
>>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
>> $ #but gpsd is still running. Here I unplug and see if ttyUSB0 goes
>> $ ps ax|grep gps
>>   3637 ?        S<sl   0:00 gpsd -F /var/run/gpsd.sock
>> $ ls /dev/ttyU*
>> /dev/ttyUSB0
>> $ #no, /dev/ttyUSB0 is still present.
>> $ sudo fuser /dev/ttyUSB0
>> $ #Empty response so nothing has it open.
>> $ #So telling gpsd to disconnect is insufficient - apart from kill -9
>> what is sufficient?
>>    
>
> Sorry to intrude, since I'm not sure if this is germane to the thread,
> but I also had an issue with gpsd holding on to devices it wasn't
> using.  But my case was bizarre: fuser showed gpsd was occupying
> /dev/parport0, the parallel port!  Killing gpsd released parport0, which
> I was using to control external hardware.
>
> Bizarre.  I had mentioned it on this list when it first happened, but
> the response (primarily disbelief) was nothing I could make use of,
> despite many strace runs.
>
> Fortunately, my GPS USB-serial interface (FTDI) had a 2K buffer, so my
> "solution" was to add a wrapper around my parallel port twiddling to do
> the following: Wait for the serial port to become idle (avoid
> interrupting a sentence), close the gpsd connection, kill gpsd, twiddle
> the parallel port, restart gpsd, then reopen the gpsd connection.  This
> was easily done fast enough to avoid GPS data loss.
>
> It's a hack of the ugliest kind, but something similar may prove useful
> as part of a temporary solution for your problem.  In my case, it worked
> because one process managed both the gpsd connection and the parallel port.
>
> In your case, you may want gpsd to be spawned/killed whenever your
> device is connected/removed.  Which means starting a gpsd instance for
> each USB-serial device when it appears, which in turn means that gpsd
> instances that do not find a GPS on a given USB serial port would need
> to be killed.
>
> For this, it would be useful if gpsd had an option that would permit it
> to "Attempt GPS discovery, then exit if no GPS found."  The equivalent
> can certainly be done manually by having the connect script start gpsd,
> sleep, attempt a connection, then kill gpsd if no connection is found.
>
> A veritable stack o' hacks, but it may work until a better solution is
> found.
>
> Perhaps the gpsd command-line options  '-b', '-n', '-N', the gpsd
> protocol commands  'b', 'f', 'g', 'k', 'n', and SIGHUP could also prove
> useful.

Hi Bob, provisionally I have come to the same conclusion as you, that I
will have to kill the daemon on each unplug. For me, with only one gps
device anyway, that is no big hardship. I will try to write up the whole
story in case anyone else wishes to follow my logic. I will try again
when Ubuntu Karmic comes out in a couple of weeks.

You did give me one good hint, that of the command "n" to gpsd. That shows,
even after unplugging, gpsd still thinks that ttyUSB0 is the current device,
hence explaining why after unplugging and replugging I only get
X=0? from gpsd, no fixes, until I restart my application.  I will let you
all know how I get on...

_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users