[26762] in Athena Bugs
Re: sunblade 150s crash with corrupt gconf
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Mar 6 19:35:24 2006
Date: Mon, 6 Mar 2006 19:34:40 -0500
From: John Hawkinson <jhawk@mit.edu>
To: Robert Basch <rbasch@mit.edu>
Message-ID: <20060307003440.GZ26428@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <682DE312-14C0-4433-9E9A-4B6738D28376@MIT.EDU>
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Robert Basch <rbasch@MIT.EDU> wrote on Mon, 6 Mar 2006
at 19:02:34 -0500 in <682DE312-14C0-4433-9E9A-4B6738D28376@MIT.EDU>:
> My guess is that the integrity check procedure (run from
> /etc/rc2.d.d/S90athena-ws on PUBLIC=true machines)
> could be the main culprit here. The athena-ws script
> echoes a warning that the check takes a few minutes
> to its standard output, but, of course, in the SMF world,
> its standard output is no longer the console. We will
> look into making the boot sequence console output
> more verbose.
Well, my debugging showed it was stuck running gconftool-2 for
several minutes, so I'm pretty sure there was something going
on there.
> /etc/gconf to /etc/gconf.broken and rebooted, the integrity check
> would have recreated /etc/gconf before the gconf schema procedure
> ran, and, in any case, I don't believe that the procedure accesses
> /etc/gconf. On m56-129-8, /etc/gconf.broken was identical to
> /etc/gconf.
Hmm. Well, then I wonder why gconftool-2 was hung.
--jhawk
