SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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
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:
# 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"
serial = "0490r39c99d40"
# overwrite global setting
bt_safe = yes
serial = "4999dfleklj5534"
# span a different daemon for this one
# and listen on different port
port = "3011"
serial = "994sle4900032"
# this adapter is temporarily disabled
enable = "no"
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.
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:
VERSION=master.6bf5d9e sh gpsd.SlackBuild
To reiterate, this is experimental - handle with care, feedback is welcome.
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:
if [ -x /etc/rc.d/rc.gpsd ]; then
While I would add the following to rc.gpsd somewhere towards the top:
if [ ! -e $GPSD_DEVICE ]; then
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.
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.
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:
# 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
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"
# 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."
# Now start one by one all devices
for GPS_RECEIVER in /dev/gps*; do
# the hotplug scripts expect the variables below in the environment
echo "$0: Starting $GPS_RECEIVER"
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.
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.