[6936] in testers
Re: install/update of 9.4
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue May 3 01:52:30 2005
Date: Tue, 3 May 2005 01:51:28 -0400
Message-Id: <200505030551.j435pSoS005751@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
CC: testers@MIT.EDU
In-reply-to: <1115050953.17500.243.camel@egyptian-gods.mit.edu>
> This experience mirrors mine and Bob Basch's: the process is doing a
> close() at the time of attach, and unsticks immediately when the
> process is attached to and detached. The precise location of the
> close() varies.
I saw this problem again myself, on a machine freshly updated to 9.4.
I was wrong about the precise location of the close() varying, I
think; in all the stack traces we've seen, it's been opening
~/.gconf/.testing.writeability to see if the homedir gconf source is
writable.
However, after attaching to gconfd-2 and detaching to unstick it, I
saw a very similar problem in mkfontscale, which was being run by
gnome-settings-daemon. That's a native program compiled without
symbols, but it was fclose()ing something. Again, attaching to the
process and detaching unstuck it, and my login session finally
proceeded.
I wrote a short C program to open and close a file in my homedir over
and over again to see if I could reproduce this problem, but I
couldn't. (I did the same steps as gconfd-2 does, and build with
-pthreads so that system calls were coming from the pthreads library.)
I guess the next step is to see whether anything in Red Hat's bugzilla
mentions this (it could be a problem in the pthreads system, in the
kernel, or in AFS, I think, and other people may have seen the problem
if it's in the former two), and to keep working on a reproduction
recipe.
