Bug 219750

Created attachment 143734 [details]
A small C program to talk to a socket.

There is probably a program that does what the C program does, or the Python
code from the supplied hotplug script could be used to do the same thing. The
script checks that gps is realy running, insteadof relying on the pid file
because gpsd does not remove the pid file it created when you kill it. Outside
of that, not much error checking is done. 

Can you try getting the USB id (from lsusb -v), put that into the
/etc/hotplug/usb/gpsd.usermap file as appropriate, restart the hotplug system,
and see if /etc/hotplug/usb/gpsd.hotplug is executed as appropriate when you
plug in your gps?  My guess is that you have a gps with a new enough usb id that
it hasn't made it into the usermap file yet.  

(In reply to comment #3)
> Can you try getting the USB id (from lsusb -v), put that into the
> /etc/hotplug/usb/gpsd.usermap file as appropriate, restart the hotplug system,
> and see if /etc/hotplug/usb/gpsd.hotplug is executed as appropriate when you
> plug in your gps?  My guess is that you have a gps with a new enough usb id that
> it hasn't made it into the usermap file yet.  

It is in the stock gpsd.usermap file. (The PS-360 OEM entry.) It works on
systems that use hotplug, but not where udev is handling hotplug events. You can
see that the SYSFS{idVendor} and SYSFS{idProduct} match the values for the
PS-360 OEM line in gpsd.hotplug. There work in the udev rules, so they must
match the device I am using.
 

I am sure that the /etc/hotplug does not work any more at all in FC5+.
Hotplugging must be done using udev and hal, so the the hotplug scripts in the
gpsd package are useless.

Udev is susposed to be able to run the Hotplug scripts, but I am not sure that
it is working. From /etc/udev/rules.d/51-hotplug.rules:

LABEL="hotplug_comp"                                                            
# compatibility support for the obsolete hotplug.d and dev.d directories        
ENV{UDEVD_EVENT}=="1",  RUN+="/lib/udev/udev_run_hotplugd"                      
RUN+="/lib/udev/udev_run_devd"                                                  

But I am not sure what is susposed to set UDEVD_EVENT to 1.

I see. But it seems that /lib/udev/udev_run_hotplugd runs scripts in
/etc/hotplug.d, and not /etc/hotplug.

Sorry I've been ignoring this for so long.  

I've only started to look into getting this to work with native udev, but when I
upgraded gpsd to the most recent version, I did change from hotplug to
hotplug.d, which may let the hotplug compatability scripts run.  Unfortunately,
I don't have a USB GPS, so I've never been able to test this.  

Let me know if gpsd-2.34-1 fixes things for you.  (It was just built; it'll be
on the mirrors in 1-48 hours).  

It seems to me that the support for the obsolete hotplug.d doesn't work. After
some testing I found out that udev_run_hotplugd is called without arguments by
udev when the usb device is plugged in. udev_run_hotplugd then looks at
/etc/hotplug.d/default (which doesn't exist). If udev_run_hotplugd is called
(manually) with the argument usb it will effectively look into the
/etc/hotplug.d/usb directory. It then simply executes gpsd.hotplug without
looking at gpsd.usermap.
So I suggest to forget about the obsolete hotplug stuff and do it the right way.

It still does not work. In the logs, I get:

Mar  1 14:07:28 mikkel kernel: usb 2-1: new full speed USB device using uhci_hcd
and address 2
Mar  1 14:07:28 mikkel kernel: usb 2-1: configuration #1 chosen from 1 choice
Mar  1 14:07:28 mikkel kernel: usbcore: registered new interface driver usbserial
Mar  1 14:07:28 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for generic
Mar  1 14:07:28 mikkel kernel: usbcore: registered new interface driver
usbserial_generic
Mar  1 14:07:28 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core
Mar  1 14:07:29 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for pl2303
Mar  1 14:07:29 mikkel kernel: pl2303 2-1:1.0: pl2303 converter detected
Mar  1 14:07:29 mikkel kernel: usb 2-1: pl2303 converter now attached to ttyUSB0
Mar  1 14:07:29 mikkel kernel: usbcore: registered new interface driver pl2303
Mar  1 14:07:29 mikkel kernel: drivers/usb/serial/pl2303.c: Prolific PL2303 USB
to serial adaptor driver

But gpsd is never started. If I run "/lib/udev/udev_run_hotplugd usb" I get
slightly different results then Gérard Milmeister - the log shows:

Mar  1 14:14:20 mikkel gpsd.hotplug: gpsd.hotplug: exception
exceptions.IndexError yields list index out of range

and gpsd is not started. Are there more tests you would like me to run? It looks
like gpsd.hotplug is not run when the device is plugged in, and running it
manualy does not work. It may be that we need a udev rule to set UDEVD_EVENT to
one for the USB devices.

Created attachment 149046 [details]
lsusb -v listing for PS-360 OEM GPS.

(In reply to comment #10)
> It may be that we need a udev rule to set UDEVD_EVENT to
> one for the USB devices.


Well, what I need are proper UDEV rules to replace the hotplug ones.  But the
udev system makes little sense to me, and I don't have anything to test it with
(my GPS is really old-school plain RS-232).  

I have attached a hotplug rule that will be run when any of the devices in
gpsd.usermap are plugged in or removed. They are set to run a script
"/etc/udev/scripts/gpsd.dev". The ENV{GPS_DEV}="true" causes the remove rule to
be run when the device is removed. I have one script doing both, but you could
use one add and one remove script.

This is necessary because there is not vender/device information to match on
when the device is unplugged.

Created attachment 150680 [details]
udev rules for USB GPS devices.

You may want to double check that I have the vender/device IDs correct.

Created attachment 151711 [details]
A small C program to talk to gpsd using a socket.

A somewhat cleaned up version of the program to talk to gpsd when it was
started using the control socket option. I also added some error checking.

Created attachment 151712 [details]
man page for gps-ctrl

My attempt at creating a man page for gps-ctrl using manedit.

Created attachment 151713 [details]
Improved gps control script.

This is an improved version of the control script to add/remove devices used by
gpsd. It is a used version of the hotplug script, but uses the gps-ctrl program
insteadof the python commands.

Thinking about this, should we be running gpsd as a service, instead of starting
it from hotplug? We could then create a /etc/sysconfig/gpsd config file with the
socket listed there, and source the file when we want to talk to gpsd. You could
also use the standard service functions to determin in gpsd is running. Maybe
run "service gpsd start" from a udev script if gpsd is not running?

If you start gpsd using the control socket option, you are not limited to
adding/removing USB devices. You can add/remove/copntrol serial and PCMCIA GPS
devices as well. One disadvantage would be that any program that checks to see
if gpsd is running would find it running even if there are no GPS devices
currently attached. On my system, xgps will also exit if you remove the last
active GPS device.

ACTION=="add", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
ACTION=="remove", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"

worked for me.

(In reply to comment #19)
> ACTION=="add", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
> SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
> ACTION=="remove", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
> SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
> 
> worked for me.

Are you sure the remove rule gets run? When I was researching this, I found that
there was no idVendor ID to match on when doing a remove. Also, your remove rule
is trying to add the device again, instead of remove it. In any case, udev is
susposed to be able to launch the hotplug script directly - I believe that is
what  51-hotplug.rules is for.

If it would help, I have created an RPM with the udev rules, the udev script,
and the program to talk to the control socket, as well as the man page for it.
The .spec file could be cleaned up, but before I spend the time, I want to see
if it is wanted.

(In reply to comment #21)
> If it would help, I have created an RPM with the udev rules, the udev script,
> and the program to talk to the control socket, as well as the man page for it.
> The .spec file could be cleaned up, but before I spend the time, I want to see
> if it is wanted.
> 

Yes, it is wanted (as long as it, obviously, doesn't interfere with plain old
gpsd operation).  Unfortunately, I can't test much (if any) of this, I only have
an old-school serial line gps.  

On a slightly unrelated note, Mikkel, are you a Fedora contributor?  Since I
really can't debug much about this package anymore I've been considering
orphaning it and letting someone else (who can use it) take it over.  

Created attachment 199961 [details]
An add-on package for gpsd.

A tempary fix for hotpluging UPS attached GPS devices.

Sorry for the delay. Here is the source RPM. I do not see how it could interfere
with the normal operation, but I could be wrong. It will start gpsd if it is not
running, the same as the hotplug script would. It looks like the next release of
gpsd will have udev rules, so this will no longer be needed.

On your other note, no I am not a Fedora contributor. I probably should become
one. I started using Fedora with FC5, and I have not moved to F7, except for a
test machine. (On the other hand, I was using RedHat before there was a
Fedora...) I will have to think about taking on the responsibility of taking
care of this package.

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

I worked with the upstream provider, so the next release should take care of the
problem.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Please close this bug when it is addressed in Fedora.  We do not use the
RELEASE_PENDING state.  changing to ASSIGNED

I believe we've had a gpsd release since this was last discussed; can anyone confirm whether this is still an issue?

(In reply to comment #29)
> I believe we've had a gpsd release since this was last discussed; can anyone
> confirm whether this is still an issue?

I'm using a fresh install of Fedora 10 with gpsd-2.37-2.fc9.i386
My GPS is a Keymaze 300

Here output of lsusb
Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

The hotplug script /etc/hotplug.d/usb/gpsd.usermap
include (by default) an entry for my GPS

# The Prolific Technology 2303 (commonly in tandem with SiRF chips)
gpsd.hotplug 0x0003 0x067b 0x2303 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000

But, still no GPSD daemon when GPS is plugged.
(started by hand fix the problem)

Maintainer: To try to fix a problem in a package you maintain, take suggested patches from the other contributors to the Bugzilla comments and apply them to the source package, then build it and upload the resulting packages to testing. Users can then test the fixed packages and let you know if they work.

Although it would be lovely if just waiting a few months and posting "Can anyone confirm whether this is still an issue?" fixed bugs, unfortunately it doesn't. In fact it's worse than useless since it just fills the bug report with noise. If you haven't heard otherwise the bug still exists. Make sure that each "can anyone...?" message offer users something new to try out which might fix their problem, otherwise they have no incentive to do anything.

There is a better fix in the SVN tree, and should be included in the next release of GPSD. It works with Udev to create a /dev/gps? symlink for the USB device, and then runs the hotplug wrapper that sends the correct connect/disconnect information to the hotplug script. The hard part on the disconnect is that udev does not have the USB information to test on the disconnect, but you can still test the symlink when a USB device is disconnected.

This is a much better fix then my patches here. The could be deleted, as the information in the SVN tree makes them obsolete.

gpsd 2.39 should have improved udev/hotplug support; I'm not sure if it works in all situations yet, so let me know how things are.

An update for my #30 comments as I've just tried gpsd-2.39-3.fc10.i386 package:

Now, "gpsd" start when my "Keymaze 300" is plugged.

but, It does not exit when I unplug my GPS...
here msg from dmesg and some output of my console.

dmesg
----8<--------8<--------8<--------8<--
pl2303 2-1:1.0: device disconnected
----8<--------8<--------8<--------8<--

----8<--------8<--------8<--------8<--
[root ~]# /etc/init.d/gpsd status
gpsd (pid 8155) is running...

[root@bebe ~]# /etc/init.d/gpsd stop
Stopping gpsd:                                             [  OK  ]
----8<--------8<--------8<--------8<--

How to check / trace is there something wrong in a script ?

Another thing, my "Keymaze 300" is know as a broken device
so I need to start gpds with "-b" option. 
I've updated to the /etc/sysconfig/gpsd file for that.
OPTIONS="-b -n"

Maybe it's a good idea to warn the user (maybe at install time)
that some GPS can be broken using default option (=> link to the man page 
of gpsd, or just a tips like use "-b" for safe session...

There is no gpsd 2.39 in the signed updates, so I looked on koji, is that what you intended Douglas ?

The package from koji, gpsd-2.39-3.fc9.i386 is broken. The gpsd binary is installed as /usr/sbin/gpsd, but the init.d script looks for it in /usr/bin/gpsd and of course this can't work.

I don't know if other problems are fixed, the lack of working init script seems like a showstopper.

(In reply to comment #35)
> There is no gpsd 2.39 in the signed updates, so I looked on koji, is that what
> you intended Douglas ?
> 
> The package from koji, gpsd-2.39-3.fc9.i386 is broken. The gpsd binary is
> installed as /usr/sbin/gpsd, but the init.d script looks for it in
> /usr/bin/gpsd and of course this can't work.
> 
> I don't know if other problems are fixed, the lack of working init script seems
> like a showstopper.  

gpsd 2.39 will most likely not make it into F9 or F10 as it has a soname bump which breaks compatibility with other apps.

I'll have to take a look at the packaged location of gpsd; sbin doesn't seem like the proper place if it's able to be run out of udev now.

(In reply to comment #34)
> How to check / trace is there something wrong in a script ?

I'm not sure; you'd have to ask gpsd-dev.
 
> Another thing, my "Keymaze 300" is know as a broken device
> so I need to start gpds with "-b" option. 
> I've updated to the /etc/sysconfig/gpsd file for that.
> OPTIONS="-b -n"
> 
> Maybe it's a good idea to warn the user (maybe at install time)
> that some GPS can be broken using default option (=> link to the man page 
> of gpsd, or just a tips like use "-b" for safe session...  

/etc/sysconfig is a common place on Red Hat/Fedora systems to configure daemons;  if your Keymaze 3000 has a unique usb id (ie, isn't detected through a serial converter) then we can probably add something to make the '-b' automatic.  Otherwise there will always be configuration required.

(In reply to comment #37)
> > Another thing, my "Keymaze 300" is know as a broken device
> > so I need to start gpds with "-b" option. 
> > I've updated to the /etc/sysconfig/gpsd file for that.
> > OPTIONS="-b -n"
> > 
> > Maybe it's a good idea to warn the user (maybe at install time)
> > that some GPS can be broken using default option (=> link to the man page 
> > of gpsd, or just a tips like use "-b" for safe session...  
> 
> /etc/sysconfig is a common place on Red Hat/Fedora systems to configure
> daemons;  if your Keymaze 3000 has a unique usb id (ie, isn't detected through
> a serial converter) then we can probably add something to make the '-b'
> automatic.  Otherwise there will always be configuration required.  

My first msg was not enought clear... If you plug a KeyMaze 300 without "-b" for GPSD, then, the keymaze 300 become useless! So, it would be nice 
to warn the user before... Currently , there is no way to precisely identify 
the keymaze 300 (unique USB id...)

I let you read this email about that.
http://www.nabble.com/Decathlon-Geonaute-Keymaze-300-td16187800.html

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.