[solved] udev rule not starting gpsd during boot

55020 · 05-30-2011, 04:23 PM

Yes, the general approach sounds good and I've grabbed a copy of your rc script. It's too late for the 2.96 update, which has already been approved, but I'll definitely include this with the SBo SlackBuild next time, though it probably won't be fully enabled by default, to avoid surprises for people upgrading. gpsd 3.0 will be a big update anyway, as it's going over to cmake -- I already have an early draft and I'll update it and put it on github in the very near future.

As I said before, thanks for poking this with a pointy stick. It's been on my TODO list (near the bottom, just above "do proper backups") for a very long time and you've helped a lot

xj25vm · 05-30-2011, 05:45 PM

I am the one who should thank you for answering my questions, throwing in ideas and generally for any work you do for SBo. As a slacker, I find it very useful.

I've sent an email to both the gpsd-users and gpsd-dev lists suggesting that they might consider moving to a standard /etc/gpsd.conf file, with [global] and [device_name] type sections, based on serial number of devices (as hardware id's are unreliable for gps devices), and a gpsdconf command line wizard which can be run every time a new usb adapter is used for the first time - which would update gpsd.conf with the correct serial number, and any options the user might wish for that adapter. The whole process would be akin to pairing up with a gpsd adapter/receiver - the way bluetooth devices get paired up the first time they connect. This way, gpsd could use inotify (or something else) to know when a new ttyUSBx or ttySx device is plugged in, and if the serial number is in gpsd.conf, it would connect to it automatically. No more udev, no more gpsd.hotplug and gpsd.hotplug.wrapper and the rest of the complication. All would one do is start the gpsd binary on system startup, and be done with it.

In my mind, this would be a wonderfully simplified system - but I'm not holding my breath over it getting any traction. I could have equally missed something important in my grand scheming anyway :-)

I'll mark this thread as solved now - as I think it is as solved as it will ever get considering all factors involved. Thanks again for all your help.

P.S. Here is my idea of a /etc/gpsd.conf file:

Code:

#/etc/gpsd.conf
[global]
# port gpsd is listening on
port = "2947"
# socket for clients passing commands to gpsd
socket = "/var/run/gpsd.sock"
# start poling devices immediately
no_wait = "yes"
# don't re-configure the device
bt_safe = "no"

[my_gps_1]
serial = "0490r39c99d40"
# overwrite global setting
bt_safe = yes

[my_gps_2]
serial = "4999dfleklj5534"
# span a different daemon for this one
# and listen on different port
port = "3011"

[my_gps_3]
serial = "994sle4900032"
# this adapter is temporarily disabled
enable = "no"

xj25vm · 06-11-2011, 03:22 AM

I'm attaching a modified version of the rc.gpsd script as I've discovered two bugs in the previous version. I've also added some comments at the top to explain why this script is necessary under Slackware. I'm hoping 55020 you are still monitoring this thread.

55020 · 06-12-2011, 05:53 AM

Hi Sebastian, have a look at http://github.com/idlemoor/SBo-fork/...edingEdge/gpsd which I have been working on for a while -- this is a experimental preview of what will become the SBo SlackBuild when gpsd-3.0 is released. It now includes your new rc.gpsd, revised somewhat. Among the changes, it uses /dev/gps0 instead of /dev/ttyUSB0 (thus allowing coexistence of a GPS with any other USB serial devices, if they are distinguishable to udev). This isn't enabled by default. Read the README.

The README also points out that there is now a dependency on scons, which is available from SBo.

Before building gpsd, you'll need to make a tarball from the gpsd project's git repository. If you're comfortable doing that, fine, otherwise you can use the repo2tarball script I've been hacking lately, which is in a parallel subdirectory in the BleedingEdge section of my github. This will clone/pull from the remote git repo, and create a tarball named something like gpsd-master.6bf5d9e.tar.gz. You then build gpsd from this tarball and install/upgrade the package as usual:

Code:

repo2tarball gpsd
VERSION=master.6bf5d9e sh gpsd.SlackBuild
upgradepkg /tmp/gpsd-master.6bf5d9e-x86_64-1_SBo.tgz

To reiterate, this is experimental - handle with care, feedback is welcome.

xj25vm · 06-12-2011, 10:28 AM

I've had a look at github and I like the look of things. One minor suggestion. If it would be me, I would keep all the options inside rc.gpsd - and keep the part that goes into rc.local as minimal as possible. So in rc.local I'd put something like:

Code:

if [ -x /etc/rc.d/rc.gpsd ]; then
  /etc/rc.d/rc.gpsd start
fi

While I would add the following to rc.gpsd somewhere towards the top:

Code:

if [ ! -e $GPSD_DEVICE ]; then
  exit 1
fi

for a quiet exit, or make it more verbose. This way the bit in rc.local looks more "traditional" or in line with other similar statements that go in rc.local, and /dev/gps0 doesn't end up being hardwired in rc.local - so that it would need changing in two different locations (rc.local and rc.gpsd) if somebody wants to use a different device name for any reason.

I like your "GPSD_SOCKARG" idea - I couldn't think of a suitable name for that variable.

55020 · 06-12-2011, 11:03 AM

Will do. In particular, you're right about the device name and it makes mincemeat of the bogus reason why I did it that way. Ta!

xj25vm · 06-12-2011, 11:22 AM

I was just looking at the udev rule supplied by the gpsd team. I just realised that, if several usb-to-serial devices are plugged in (not necessarily all gps receivers) - there is no guarantee that the gps receiver will end up under /dev/gps0. They use "SYMLINK+="gps%n" which I believe means that it will take the same number assigned by the kernel to /dev/ttyUSBx which is linking to. There could be only one gps receiver plugged (next to other usb-to-serial devices) and still end up as /dev/gps3 or /dev/gps4. And no way to control this with the current settings. In the light of this, the way I see it there are two options:

1. Modify the udev rule and recommendation, so that people hardwire their own device number e.g. instead of using "SYMLINK+="gps%n" use "SYMLINK+=gps0".
2. Or, modify rc.gpsd, by removing GPSD_DEVICE variable, and instead do something like "ls /dev/gps*", check if anything comes out of that, and if yes, for first device found start gpsd on it. That of course makes the willing assumption there is only one gps receiver plugged in when the computer starts, and/or ignores any other.

Otherwise we would deal with a situation where rc.gpsd relies on the chance that the gps receiver is the first one to be polled by udev of any serial-to-usb devices connected - which, I would think, is very flimsy. It also pretty much ruins one of the main purposes of using udev for this - which, I believe, was to deal with having several usb-to-serial devices plugged in.

Unless I'm misunderstanding the udev rules.

xj25vm · 06-12-2011, 02:16 PM

I worked a bit on the latest version of rc.gpsd and I adapted it to cope with /dev/gpsx devices numbered in an unpredictable fashion. Also, I adapted it to cope with an unknown number of gps devices plugged in when the computer starts. I know this is somewhat unlikely - but I think this way it is more flexible and robust. If you think this is overkill, it could be changed to just start gpsd on the first device encountered. Here is the part of it I've modified:

Code:

# No need for the options or socket variables - as they get read
# by the hotplug script from /etc/default/gpsd. No point in having two sets of settings

gpsd_start() {

  GPS_DEVICE_COUNT=`ls -l /dev/gps* 2>/dev/null | wc -l`

  if [ "$GPS_DEVICE_COUNT" -eq "0" ]; then
    echo "$0: No /dev/gps found. Will not start gpsd"
    exit 1
  fi

  #  will check only for hotplug scripts - the only ones we need directly
  if [ ! -x /lib/udev/gpsd.hotplug -o ! -x /lib/udev/gpsd.hotplug.wrapper ]; then
    echo "$0: no gpsd hotplug scripts (or not executable); cannot start."
  fi

  # Now start one by one all devices
  for GPS_RECEIVER in /dev/gps*; do
    # the hotplug scripts expect the variables below in the environment
    export OPTIONS="$GPSD_OPTIONS"
    export ACTION="add"
    export DEVNAME="$GPS_RECEIVER"
    echo "$0: Starting $GPS_RECEIVER"
    /lib/udev/gpsd.hotplug.wrapper
  done

}

It feels a bit like going in one big circle - and ending close to where I started - but I think the code above should take care of everything. One of these days when I'll grow some extra cells on the brain I'll have to sit down and write a C wrapper which takes care of everything properly and does all the checks - three layers of scripts to start one piece of software is really silly from where I'm standing. Then again, after trying for 2 days to convince the project leader for gpsd to make life a bit easier for those who interact with his software - I'm not holding my breath there will be any change from that direction.

55020 · 06-14-2011, 11:55 AM

Sorry for using this thread to conduct a dialogue of diminishing public interest, but I've just pushed a new set of gpsd files to Github, including fixes for the device numbering issue Sebastian pointed out, the config issue, and patches for a number of ghastly upstream problems.

There is now a config file at /etc/rc.d/rc.gpsd.conf, which is where it should be in any distro of good taste and discernment

I might try to do an LQ Blog about this, so that we have somewhere else to discuss any matters arising.