[26761] in Athena Bugs
Re: sunblade 150s crash with corrupt gconf
daemon@ATHENA.MIT.EDU (Robert Basch)
Mon Mar 6 19:04:15 2006
In-Reply-To: <20060306223244.GY26428@multics.mit.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <682DE312-14C0-4433-9E9A-4B6738D28376@MIT.EDU>
Content-Transfer-Encoding: 7bit
From: Robert Basch <rbasch@mit.edu>
Date: Mon, 6 Mar 2006 19:02:34 -0500
To: John Hawkinson <jhawk@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
On Mar 6, 2006, at 5:32 PM, John Hawkinson wrote:
> Do we know why it was painfully slow?
Because it's a SunBlade 150? :)
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.
> I assume it was related to
> the presence of /etc/gconf.
This could have been a red herring. Note that when
you moved /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.
Bob
