[prev in list] [next in list] [prev in thread] [next in thread]
List: gpsd-users
Subject: Re: [Gpsd-users] Unplugging USB gps receivers - gpsd behaviour.
From: Two Sank <sanktwo () attglobal ! net>
Date: 2009-10-22 11:53:26
Message-ID: 4AE047B6.1010609 () attglobal ! net
[Download RAW message or body]
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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/gpsd-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic