Re: mozilla hanging on gconfd2 startup?

On Sun, 29 Feb 2004, Joe Marcus Clarke wrote:
> On Sun, 2004-02-29 at 00:20, Nate Lawson wrote:
> > On Sat, 28 Feb 2004, Joe Marcus Clarke wrote:
> > > On Sat, 2004-02-28 at 21:08, Nate Lawson wrote:
> > > > On Sat, 28 Feb 2004, Joe Marcus Clarke wrote:
> > > > > On Sat, 2004-02-28 at 18:27, Nate Lawson wrote:
> > > > > > I can't seem to start mozilla after upgrading the port today.  It
> > > > > > starts a process called gconfd2 which never completes.  I'm running
> > > > > > a current as of Friday.
> > > > >
> > > > > Weird.  Seems Mozilla will try to use gconf2 if found (this is neither a
> > > > > compile-time nor runtime dependency).  However, all of the GConf methods
> > > > > are unimplemented.  The gconf hang problem may be related to the recent
> > > > > reentrant resolver patches so rebuilding devel/gconf2 should fix the
> > > > > problem.
> > > >
> > > > This doesn't work.
> > >
> > > I'd be curious to know (if you don't mind) if rebuilding ORBit2 fixes
> > > this.  I'd test this myself, but I'm not at my -CURRENT GNOME machines
> > > at the moment.  Thanks.
> >
> > Nope.  Still get this hanging in "select":
> >  1000 33625     1   0  76  0  6932 5444 select S     ??    0:00.10 /usr/X11R6/libexec/gconfd-2 12
>
> Could you break into this with gdb, and get a back trace just to see
> what this guy is trying to do?  Thanks.

(gdb) bt
#0  0x28313397 in poll () from /lib/libc.so.5
#1  0x281331a1 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5
#2  0x28132be1 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5

> I know I've seen gconfd hang when starting up on -CURRENT with an
> NFS-mounted home if rpc.lockd wasn't running on the server.  I've also
> seen problems where the local hostname wasn't resolvable or if there was
> a permissions problem on /tmp or /var/tmp.

No NFS mounts.  The local hostname is not resolvable.  A tcpdump shows
this:

tcpdump: listening on fxp0
16:50:35.000326 laptop.49457 > mydns.53:  60862+ A? laptop.example.org. (36)
16:50:35.067216 mydns.53 > laptop.49457:  60862 NXDomain* 0/1/0 (94)
16:50:35.067602 laptop.49458 > mydns.53:  60863+ A? laptop. (24)
16:50:35.206926 mydns.53 > laptop.49458:  60863 NXDomain 0/1/0 (99)
16:50:35.209422 laptop.49459 > mydns.53:  60864+ A? laptop.example.org. (36)
16:50:35.242605 mydns.53 > laptop.49459:  60864 NXDomain 0/1/0 (105)
16:50:35.242745 laptop.49460 > mydns.53:  60865+ A? laptop. (24)
16:50:35.408390 mydns.53 > laptop.49460:  60865 NXDomain 0/1/0 (99)
16:50:35.410527 laptop.49461 > mydns.53:  60866+ A? laptop.example.org. (36)
16:50:35.477876 mydns.53 > laptop.49461:  60866 NXDomain 0/1/0 (105)
16:50:35.478001 laptop.49462 > mydns.53:  60867+ A? laptop. (24)
16:50:35.634809 mydns.53 > laptop.49462:  60867 NXDomain 0/1/0 (99)

So it does appear that the hostname is the issue.  However, on a mozilla
1.5 and a -current of a few weeks ago, this was not a problem.  So what
changed?

Oh, and it looks like we need to start randomizing our xids.

-Nate