Re: gconfd process eating CPU

[Brian Cameron <Brian Cameron Sun COM>]

Mark:

> > > > 4335/1 1:	 1.0220	                -> liblinc:linc_connection_read(0x34900, 0x14418c, 0x0, 0x0)
> > > > 4335/1 1:	 1.0222	                  -> liblinc:d_printf(0xff1e5bb0, 0x0, 0xa, 0x0)
> > > > 4335/1 1:	 1.0224	                  <- liblinc:d_printf() = 0xff1e5bb0
> > > > 4335/1 1:	 1.0228	                <- liblinc:linc_connection_read() = 0
> > >
> > >  -> Here we read the connection and find that it returns zero. That 
> > >     means the other side of the connection has closed. Looking at 
> > >     recent ORBit code I'd expect linc_connection_state_changed() to
> > >     be called and we'd close our side and remove the source
> >
> > This makes sense, although looking at the code for link_connection_io_handler
> > (both the older code and the current CVS code), I don't see how
> > link_connection_state_changed could get called in this scenario. 
>
> 	Right, linc_connection_read() returns LINC_IO_FATAL_ERROR if read()
> returns zero. So, the other side isn't closing the connection then - or
> at least that's not what a zero return from linc_connection_read()
> means.
>
> 	So, linc_connection_read() is being passed len == 0. Looking at the
> code, the only way that could really happen is if a previous read
> returned an error and state_changed (LINC_DISCONNECTED) didn't cause the
> watch to be removed.

Do you have any suggestions how I might be able to track down what filehandle
has entered this invalid state?  Perhaps if we could identify which program
GConf thinks its talking to, it might highlight what the problem might be.

> 	Dunno, you'd need a debug log from the time when the connection got
> into that state.

Do you mean the GCONF debug log that is set by adding this line to
/etc/syslog.conf:

  user.debug              /var/log/user

Or another, say ORBit2 log, mechanism?  We can certainly turn on debug
logging on one of the multi-user servers where we tend to see this problem
keeps popping up.

Do you think it might be an option to make linc a bit smarter so that
if it gets stuck in a loop where it keeps reading 0-length data, that we
could go ahead and drop the connection?

--

Brian