Re: [gpsd-dev] GPSD terminating with select error

[Eric S. Raymond]

Roy Barkas <address@hidden>:
> I start gpsd to source it's input from a pair of tcp ports as:
> 
> /usr/local/sbin/gpsd -b -D1 -F /tmp/gpsd.sock tcp://localhost:46001
> tcp://localhost:46002
> 
> All works fine until/unless one of the applications that serve data on
> ports 46001 or 46002 die.
> 
> When the application that provides the tcp port dies, gpsd dies as well.
> The only thing in the gpsd.log that seems relevant is:
> 
> gpsd:ERROR: select: Bad file descriptor
> 
> I'm using gpsd in a way that relies on it being a robust daemon, capable of
> recovering from unclean disconnects or similar events.
> 
> I haven't looked at the gpsd source code yet.
> Is there anything wrong with the way that I'm starting gpsd?

No, there isn't.

What I think is happening is that the bad file descriptor is the one
corresponding to whatever TCP/IP connection just died, and the
select() call that is failing is the one in the main loop.

Because of the way the sockets API is written, recovering from this
is going to be nasty.  The only way I can imagine it working is that on
EBADF the main select calls a special handler that walks through its set
of active file descriptors looking for any have gone south and removing
them from the set.  Then the select loop is resumed.

The sticky part is that I'm not sure what the right test for badness 
would be to run on the individual descriptors.  Developers, any ideas
about this?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>