Date: Mon, 01 Mar 2004 18:17:53 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Nate Lawson <nate@root.org> Cc: current@freebsd.org Subject: Re: mozilla hanging on gconfd2 startup? Message-ID: <1078183073.779.40.camel@gyros> In-Reply-To: <20040229170401.Q3406@root.org> References: <20040228152618.C98870@root.org> <1078019158.18071.12.camel@shumai.marcuscom.com> <20040228180719.W99350@root.org> <1078020761.18071.15.camel@shumai.marcuscom.com> <20040228211904.T99760@root.org> <1078032512.20048.7.camel@shumai.marcuscom.com> <20040229164555.G3406@root.org> <1078102552.62463.64.camel@shumai.marcuscom.com> <20040229170401.Q3406@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-9xBOO5GZtBLyz4Z8Leqd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-02-29 at 20:07, Nate Lawson wrote: > On Sun, 29 Feb 2004, Joe Marcus Clarke wrote: > > On Sun, 2004-02-29 at 19:53, Nate Lawson wrote: > > > On Sun, 29 Feb 2004, Joe Marcus Clarke wrote: > > > > > Nope. Still get this hanging in "select": > > > > > 1000 33625 1 0 76 0 6932 5444 select S ?? 0:00.1= 0 /usr/X11R6/libexec/gconfd-2 12 > > > > > > > > Could you break into this with gdb, and get a back trace just to se= e > > > > 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/li= bc_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 a= lso > > > > seen problems where the local hostname wasn't resolvable or if ther= e was > > > > a permissions problem on /tmp or /var/tmp. > > > > > > No NFS mounts. The local hostname is not resolvable. A tcpdump show= s > > > this: > > > > > > tcpdump: listening on fxp0 > > > 16:50:35.000326 laptop.49457 > mydns.53: 60862+ A? laptop.example.or= g. (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.or= g. (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.or= g. (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 mozi= lla > > > 1.5 and a -current of a few weeks ago, this was not a problem. So wh= at > > > changed? > > > > The gconf "dependency" was most likely added in 1.6. The solution to > > this is to add your local hostname to /etc/hosts (that's the common > > answer to GNOME users encountering this lock in gconfd). If you don't > > want to do that, the pref trick is another valid workaround, but I thin= k > > the hostname thing makes more sense. >=20 > Attempts to add the hostname as 127.0.0.1 and the actual IP resulted in a > hang in the same place. A tcpdump of both lo0 and fxp0 show no more DNS > queries so the hosts entry was definitely being used. A telnet to the > hostname also shows that the lookup succeeds. Since there were no > segments of TCP or UDP, I'm at a loss why it is blocking still. I'm not able to reproduce this after upgrading to today's -CURRENT, and rebuilding Mozilla, ORBit2, and gconf2. I'm using ULE and libpthread.=20 Perhaps tomorrow I'll try it with libc_r (I assume you're using libc_r since you have the nVidia drivers?). Joe >=20 > -Nate --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-9xBOO5GZtBLyz4Z8Leqd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAQ8Shb2iPiv4Uz4cRApL2AJ9C/Yw43PFFEqcQTn3TvDk3qGwVWACdFxf1 1okdbzXkVQKY0Mcv6BbS/kg= =Bzfb -----END PGP SIGNATURE----- --=-9xBOO5GZtBLyz4Z8Leqd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1078183073.779.40.camel>