Re: [gamin] gamin abstract socket bind() probem



On Wed, Aug 04, 2004 at 09:55:37AM -0400, Daniel Veillard wrote:
> On Wed, Aug 04, 2004 at 09:39:23AM -0400, John McCutchan wrote:
> > On Wed, Aug 04, 2004 at 09:26:31AM -0400, Daniel Veillard wrote:
> > >   I have no idea why. I can't find when logging the applications what might be
> > > going wrong and where. All the logs I collect only show correct behaviour
> > > but I get that pop-up window if fam_server is not started before running
> > > gnome-session. strace'ing broke the whole desktop startup altogether.
> > > I don't see any application crash, so far the issue is still open, everything
> > > seems to behave normally, the gnome-settings-daemon is actually running...
> > 
> > I made a wrapper script around gam_server that outputted the debug
> > log to a file. It is still the same problem of two gam_server's starting
> > up. One succeeding in getting the socket the other failing.
> 
>  But failure to start should not kill the application, the client code
> should just come back and it will retry to connect to the socket anyway.
> Since the socket does exist at that point it should just be able to connect.
> 

You are right it shouldn't kill the application. I don't even know if
gnome-settings-daemon is actually dying. Do you know of a program
that will record process timeline? Even though gnome-settings-daemon is
running, it is not running properly, it doesn't detect gtk theme
changes.

> > gnome-settings-daemon is indeed running, but try changing your gtk theme
> > in the theme manager and it will fail to notice it. One work around this
> > is to add gam_server to your session and make sure it is loaded first.
> > 
> > Maybe if the gam client retried for 5 seconds or until it connected to the
> > gam_server or spawned a gam_server that works? But that still feels
> > hacky to me.
> 
>   Why ? The client has to reissue a connection to the new server anyway,
> whether it's the one it forked or another one, there is only one socket
> registered at the system level, and connect'ing to it should work just fine
> then.

What I thought was hacky was the 5 second timeout. I do think the
right solution is the client trying to connect again.

John



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]