I'm having a problem starting GPSD on a Beaglebone Green. I get a socket bind error:

root@BBG1:/etc/init# gpsd -D3 -n -N /dev/ttyUSB0
gpsd:INFO: launching (Version 3.16)
gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
gpsd:ERROR: can't bind to IPv6 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
gpsd:INFO: command sockets creation failed, netlib errors -1, -1

It appears the issue is common on these mini dev boards (Raspberry Pi included) but what seems to fix the problem for most people hasn't worked for me. Near as I can tell, it's because systemd/init are beating gspd to it.

root@BBG1:/etc/init# netstat -lnpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0  *               LISTEN      1/init
tcp        0      0  *               LISTEN      375/connmand
tcp        0      0    *               LISTEN      493/sshd
tcp6       0      0 ::1:2947                :::*                    LISTEN      1/init
tcp6       0      0 :::8080                 :::*                    LISTEN      631/apache2
tcp6       0      0 :::80                   :::*                    LISTEN      1/init
tcp6       0      0 ::1:53                  :::*                    LISTEN      375/connmand
tcp6       0      0 :::22                   :::*                    LISTEN      493/sshd
tcp6       0      0 :::1880                 :::*                    LISTEN      1/init
tcp6       0      0 :::3000                 :::*                    LISTEN      1/init

I've tried:

  1. modifying /lib/systemd/system/gpsd.socket to change ListenStreamfrom to but when I reboot, init binds to that instead (as seen in code block above).
  2. sudo killall gspd and then restarting again, but that doesn't seem to help.
  3. modify /etc/default/gpsd to the following:

  4. a custom boot script in /etc/rc.local (supposed to delay the startup of gpsd, but it doesn't seem to be running because the startgpsd.txt file never updates)

    #Start the gpsd daemon
    exit 0

which points to startgpsd.sh

    #!/bin/sh -e
    #Need to wait past boot so everything is done
    date "+%Y-%m-%d %H:%M:%S" > /startgpsd.txt
    sleep 2
    echo "Starting GPSD" >> /startgpsd.txt
    /usr/local/sbin/gpsd /dev/ttyUSB0 -G -n -F /var/run/gpsd.sock
    date "+%Y-%m-%d %H:%M:%S" >> /startgpsd.txt
    exit 0

At one point when I upgraded GSPD from v 3.11 (downloaded with apt-get) to v 3.16 (downloaded the binary and a gig+ of other crap so I could build it) it started working, but as soon as I rebooted I was back to the same problem.

Is there a way to stop systemd from binding to the port so gpsd can instead (or is that even my problem)? Killing PID 1 doesn't seem like a smart thing to do, so I haven't tried that yet. I'm almost to the point of wiping everything and starting all over, but I thought I would try to harness the 'collective power of genius' here first (given that I've already found several answers to other problems here in the past).


Edit: Adding the contents of /lib/systemd/system/gpsd.socket

Description=GPS (Global Positioning System) Daemon Sockets


  • Posting the contents of " /lib/systemd/system/gpsd.socket" would be helpful. – Mark Stosberg Aug 29 '16 at 18:21

The issue here is that you have competing methods of trying to start gpsd and set up the second.

The first method you are using is systemd and socket activation. In this design, systemd sets up the second and waits for a connection to the socket. When something connects to the socket, systemd activates the service so it can respond. That's "socket activation". If you wish to use this approach, recommended reading includes this blog post about socket activation as well as the the official docs for systemd socket files.

The second method you are using is to start gpsd to run persistently via rc.local and to set up your own socket. This fails currently systemd has already tried to do this for you. If you wish to use this method and disable systemd, you can run:

systemctl stop gpsd
systemctl disable gpsd

I recommend using systemd. You don't have to use the socket activation feature if you don't want to. systemd can handle gpsd will handle restarting the daemon if it crashes, which your rc.local script does not do. systemd will also handle any logging that daemon might do, which yourrc.local script doesn't handle either.

  • I now understand what systemd does, thank you. I've commented out my rc.local script as it wasn't running anyway (the startgpsd.txt log never updated with new date and time unless I manually ran the script) and tried rebooting, but that didn't work (same result). I also tried systemctl stop gpsd and disable gpsd and then running the gpsd command again, but got the same socket error and netstat -lnpt still shows 1/init holding the port open. Now that I understand what systemd is supposed to do, I'm left baffled at why it won't let gpsd use the port. – beijota2 Aug 31 '16 at 21:43
  • I've also noticed that when I use cgps (one of the tests that supposed to help determine gpsd functionality) the data stream down in the bottom has all the needed information (meaning the GPS antenna is working, has a fix, and is transmitting data) but the table won't populate with the information, which I thought was odd. It can see it, but it won't use it. Maybe the parsing is wrong? – beijota2 Aug 31 '16 at 21:50
  • 1
    Also try systemctl stop gspd.socket to shutdown the systemd-managed socket. I thought this would be done by shutting down the gpsd service, but maybe not. – Mark Stosberg Sep 1 '16 at 13:48
  • Because I had made so many changes, I couldn't keep track of them all so I wiped and started from a fresh image. In rebuilding, I followed a tutorial for setting up GPSD for NTP (found here) which recommended disabling systemd (systemctl disable gpsd.socket and systemctl stop gpsd.service) and added GPSD_OPTIONS="-n" to /etc/default/gpsd so it would connect without waiting for a client first. In /lib/systemd/system I edited gpsd.service to comment out anything calling the gpsd.socket. So you were right. Thanks! – beijota2 Sep 2 '16 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.