bugGPSD - Bugs: bug #40299, gpsd does not start properly on...

 
 

bug #40299: gpsd does not start properly on Raspberry Pi

Submitter:  Phil <phil32767>
Submitted:  Fri 18 Oct 2013 07:08:11 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 12 Nov 2013 11:52:12 AM UTC, comment #5: 

Please refer this upstream to ther Rspbian people.  As we discyussed on IRC, it's a packaging problem rather than a GPSD bug.

Eric S. Raymond <esr>
Group administrator
Wed 23 Oct 2013 10:39:46 PM UTC, comment #4: 

Update: apparently "dpkg-reconfigure gpsd" should have been "sudo dpkg-reconfigure gpsd". I repeated the test (export ACTION and DEVNAME first) and got:
+ PATH=/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ export PATH
+ [ -r /etc/default/gpsd ]
+ . /etc/default/gpsd
+ START_DAEMON=false
+ GPSD_OPTIONS=-n
+ DEVICES=
+ USBAUTO=true
+ GPSD_SOCKET=/var/run/gpsd.sock
+ [ -n -n ]
+ export GPSD_OPTIONS
+ [ -n /var/run/gpsd.sock ]
+ export GPSD_SOCKET
+ [ -n true ]
+ [ true = true ]
+ [  = remove ]
+ logger -t gpsd.hotplug -p daemon.info
+ [ -z  ]
+ logger -t gpsd.hotplug -p daemon.err no device
+ exit 0
Note the "export GPSD_OPTIONS" have the .sock with no -F before it -- not sure if that means anything. /etc/default/gpsd contains:
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="false"
GPSD_OPTIONS="-n"
DEVICES=""
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
I used dpkg-reconfigure to add a -F in front of the socket (which put it in GPSD_SOCKET in /etc/default/gpsd). Re-power-up'ed (first disabling hotplug so it wouldn't start, then re-enabling it before repeating the test). And got exactly the same results except + export GPSD_OPTIONS changed to + [ -n -F /var/run/gpsd.sock ].

I also tried clearing the gpsd control socket location in dpkg-reconfigure, but that just resets it to /var/run/gpsd.sock (without telling you that it did)... hence just removing the -F from [ -n -F /var/run/gpsd.sock ].

No idea what to do next.

Phil <phil32767>
Sat 19 Oct 2013 12:45:52 PM UTC, comment #3: 

This is actually progress.  We have a much better idea what's going on now.  The client tests didn't work because gpsd couldn't create its control socket and died.

(There's also the configuration issue with USBAUTO, but that's trivial.)

Now we need to figure out why the control socket couldn't be created. Most likely a permisdssions problem.

BTW, sorry about not being on #gpsd last night, I was at Friday night gaming.  I'll be more available today.

Eric S. Raymond <esr>
Group administrator
Fri 18 Oct 2013 10:07:55 PM UTC, comment #2: 

I attempted <esr>'s suggestion as follows:
"sudo dpkg-reconfigure gpsd" to set start auto to no and handle USB to no, so gpsd won't run at boot (I have to do this, otherwise the only way to follow <esr>'s suggestion step 1 would be to do something like killall, which I already know masks whatever the problem is), then "sudo poweroff".

After logging in, "export ACTION=add" and "export DEVNAME=/dev/ttyUSB0". Then "cd /lib/udev/" and "sh -x gpsd.hotplug". The following text displayed:

+ PATH=/usr/sbin:/usr/lib/arm-linux-gnueabihf/libfm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
+ export PATH
+ [ -r /etc/default/gpsd ]
+ . /etc/default/gpsd
+ START_DAEMON=false
+ GPSD_OPTIONS=-n
+ DEVICES=
+ USBAUTO=false
+ GPSD_SOCKET=/var/run/gpsd.sock
+ [ -n -n ]
+ export GPSD_OPTIONS
+ [ -n /var/run/gpsd.sock ]
+ export GPSD_SOCKET
+ [ -n false ]
+ [ false = true ]
+ exit 0

It doesn't seem to get to gpsdctl. So then I did "sudo dpkg-reconfigure gpsd" to set auto USB back to YES, and (without rebooting) again typed "sh -x gpsd.hotplug". The following displayed:

+ PATH=/usr/sbin:/usr/lib/arm-linux-gnueabihf/libfm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
+ export PATH
+ [ -r /etc/default/gpsd ]
+ . /etc/default/gpsd
+ START_DAEMON=false
+ GPSD_OPTIONS=-n
+ DEVICES=
+ USBAUTO=true
+ GPSD_SOCKET=/var/run/gpsd.sock
+ [ -n -n ]
+ export GPSD_OPTIONS
+ [ -n /var/run/gpsd.sock ]
+ export GPSD_SOCKET
+ [ -n true ]
+ [ true = true ]
+ [ add = remove ]
+ logger -t gpsd.hotplug -p daemon.info add /dev/ttyUSB0
+ [ -z /dev/ttyUSB0 ]
pi@raspberrypi /lib/udev $ + [ -x /dev/ttyUSB0 ]
+ gpsdctl add /dev/ttyUSB0
gpsd:ERROR: can't listen on local socket /var/run/gpsd.sock
gpsd:ERROR: control socket create failed, netlib error -1

And then it just sits there forever. Added to syslog was:

Oct 18 00:03:03 raspberrypi gpsd.hotplug: add /dev/ttyUSB0
Oct 18 00:03:03 raspberrypi gpsdctl: gpsd_control(action=add, arg=/dev/ttyUSB0)
Oct 18 00:03:03 raspberrypi gpsdctl: launching gpsd -n -F /var/run/gpsd.sock
Oct 18 00:03:03 raspberrypi gpsdctl: launch of gpsd failed

I don't know what to do next.

Phil <phil32767>
Fri 18 Oct 2013 04:33:54 PM UTC, comment #1: 

My suspicion falls on the Raspbian hotplug system, because of the way initial startup is failing but you find the daemon works when started manually.

The way startup is supposed to work is that when you plug in a USB GPS, the script gpsd.hotplug in the source distribution is invoked by the hotplug event.  It sets up some arguments and calls gpsdctl.  gpscdctl is responsible for starting a gpsd instance if none is already running, then shipping a device-add notification to gpsd's control port.

It sounds like something goes wrong somewhere in that startup sequence, probably due to an unexpected feature of the Raspbian environment.

In your shoes I would do this:

1) Make sure the GPS is plugged in but gpsd is not running.

2) tail -f /var/log/syslog in a terminal window of its own.  You want to be able to see gpsdctl's progress messages and gpsd's startup and failure messages, if any.

2) Set ACTION to "add" and DEVNAME to "/dev/ttyUSB0". Make sure to export these variables so they'll be in gpsd.hotplug's environment.

3) Run sh -x gpsd.hotplug and watch what the script does.  If it craps out before calling gpsdctl, likely there's your problem. I don't think that will happen, though, since your report suggests gpsd is actually starting up in some sort of bad state.

4) Watch what arguments it passes gpsdctl.  (There's a gpsdctl man page.)  This is so you can replicate the startup in a simpler way on a second run.

5) When gpsdctl runs it should log the options it uses to launch gpsd.  This is what you want; running that exact command is likely to replicate your failure.

6. Once you can replicate, crank up gpsd's debugging level until something jumps out at you.

You can usually find me on the freenode #gpsd channel. We're in the same timezone. I'm willing to help you through this procedure.


Eric S. Raymond <esr>
Group administrator
Fri 18 Oct 2013 07:08:11 AM UTC, original submission:  

I'm working on a project with GPS on a Raspberry Pi, and searching the Internet I find that nearly without exception people report that gpsd does not start properly on the Raspberry Pi. At the very least, people, by and large, report having to "killall gpds" and restart it before it will function properly.

I have the latest version of the Raspberry Pi "B" from Element14, and have formatted the SD card and extracted the latest version of NOOBS_v1.3.zip (from wwww.raspberrypi.org/downloads) to it. It is powered by, and connected to, a powered hub (http://www.amazon.com/gp/product/B005P2BY5I/). Also connected to the powered hub is an ordinary USB mouse and USB keyboard (from some PC). An HDMI monitor is connected to the Raspberry Pi and a wired-Ethernet Internet connection. I booted the Raspberry Pi and installed the Raspian OS only; for configuration I changed the local to add en_US.UTF-8 and selected that as default, and set the timezone to US Pacific Ocean.

Upon booting up I did "sudo apt-get update" and "sudo apt-get install gpsd gpsd-clients python-gps" which got version 3.6-4. I then plugged a GlobalSat BU-353 USB GPS Navigation Receiver (http://www.amazon.com/gp/product/B000PKX2KA) into the powered hub, which I presume loaded the ttyUSB drivers. "tail /var/log/syslog -n50" confirmed a Prolific Technology 2303 serial port at ttyUSB0.

"cgps -s" to test the GPS device fails. "sudo killall gpsd" followed by "sudo gpsd -F /var/run/gpsd.sock -n /dev/ttyUSB0" and then "cgps -s" shows the GPS device working.

Next, "sudo nano /etc/ntp.conf" is used to add "server 127.127.28.0 minpoll 4" and "fudge 127.127.28.0 time1 0.072 refid GPS", comment out the 4 existing IPv4-based servers, and remove the comment from statsdir. "sudo dpkg-reconfigure gpsd" is used to set: start automatically yes, handle USB automatically yes, device (blank), options -n" and socket is left as shown.

Then "sudo poweroff". Unplug power to Raspberry Pi, unplug Ethernet cable from Raspberry Pi. Wait a few minutes (with power still applied to USB hub and therefore the GlobalSat BU-353). (NOTE: wait considerably less than 1000 seconds so after booting up the time will not be off by 1000 seconds or more.) Then plug power (from hub) into Raspberry Pi.

After booting up and logging in, "date" is used to check time, and the time is found to be a little later than the time when the Raspberry Pi was powered down (that is, it has NOT been updated by ntp connection to GPS). "tail /var/log/syslog -n50" was used to view errors: "can't bind to IPv4 port gpsd, Address already in use", "maybe gpsd is already running!", "can't create IPv6 socket". "tail /var/log/ntpstats/peerstats" reports there is no peerstats file.

"sudo killall gpsd", then "sudo gpsd -F /var/run/gpsd.sock -n /dev/ttyUSB0", then "sudo service ntp restart". Next I used "date" to verify the time has been set, which it has. "tail /var/log/ntpstats/peerstats" shows that ntp is logging the GPS results.

I have tried a wide variety of configurations in an attempt to simply cause ntp to set the time using GPS (without having to use "killall gpsd" or some equivalent). None of them work, though some result in different error messages from shown above. Suggestions I've found on the Internet, such as adding chmod to allow rw from all users on /dev/ttyUSB0 and disabling USB hotplug, do not work.

This is pretty much the simplest possible GPS installation on a Raspberry Pi, with as "clean" a software installation as possible, and a very simple task (updating with ntp, or testing with cgps). But from power-on it does not work. Ever. And on searching the Internet, it doesn't seem to be working for anyone else, either.

(The GPS setup could be slightly simpler by plugging the GlobalSat BU-353 directly into the Raspberry Pi, rather than into a USB hub, but I've tried that and it doesn't work either.)

Phil <phil32767>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by esr (Posted a comment)
  • -email is unavailable- added by phil32767 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-22 esr Open/ClosedOpen Closed
    2013-11-12 esr StatusNone Invalid

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code