instability on new remote server

[hughrutledge2001 at yahoo.com (Hugh Rutledge)]

On the keyboard issue,  the server is a remote, 
rackmount server and isn't supposed to have a keyboard
(though I do want it to check in case I'm there to
give it on-site instructions.)  But I also want it to
boot without making an issue of the keyboard's
absence-- when like this time the keyboard isn't
there.

Hugh


--- Derek Martin <blu at sophic.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, Dec 31, 2002 at 11:02:43AM -0500, Mark
> Hertel wrote:
> > On Tue, Dec 31, 2002 at 07:44:33AM -0800, Hugh
> Rutledge wrote:
> > > 1)  it has twice gone into non-response mode to
> most
> > > outside messages.  It would still answer ping
> and
> > > would attempt to accept ssh contacts but could
> not
> > > validate passwords and would respond to http
> requests
> > > with "not authorized" and "additional not
> privilieged"
> > > responses.
> > 
> > This sounds like the power saving has turned off
> the disks
> > and only those processes in memory are working.
> 
> While I suppose this is possible, I doubt it's
> what's going on.  In
> fact, ordinarily on Linux systems, you need to go
> out of your way to
> make it happen.  The reason is because several times
> a minute, bdflush
> syncs the disks, which causes disk activity, even if
> there hasn't been
> any I/O recently.  If you actually WANT to power
> down your disks (e.g.
> to save battery life on a laptop), you generally
> need to run a daemon
> called noflushd to keep bdflush from syncing the
> disks until there
> actually are dirty buffers to flush (i.e. some disk
> I/O has occured).
> 
> Even if this did happen, when disk activity resumed,
> the drives should
> power up pretty quickly, and resume normal
> operation.  Processes
> should block in I/O wait state until the drives are
> ready.  If they're
> not, there's probably something wrong with the
> hardware...  And if the
> disk are never ready, e.g. because of hardware
> failure, the processes
> which are waiting for them will generally block
> indefinitely (though
> this need not always be the case, depending on how
> the programs are
> written, and how the device driver deals with the
> failure).
> 
> > > 2)  on rebooting,  the tech at the site says
> that it
> > > complained about not having a keyboard and about
> its
> > > array-- but neither of these show up as warnings
> or
> > > errors in the boot.log.  
> > 
> > I've only seen the keyboard problem occur at the
> BIOS level,
> > so it doesn't get logged by Linux.
> 
> Yup.
> 
> My first guess would be a motherboard problem
> (assuming the keyboard
> IS connected).  But as I commented in my previous
> message, this sort
> of thing is probably too difficult to troubleshoot
> without being able
> to see what's going on and get feedback from the
> system.
> 
> - -- 
> Derek D. Martin
> http://www.pizzashack.org/
> GPG Key ID: 0xDFBEAD02
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
>
iD8DBQE+EeAbHEnASN++rQIRAlIFAJwJgmykdG7Zt+gX9fvvLlxVu5/APwCeL8/k
> ZUsXWgqsik84rB55VUT129o=
> =+PL/
> -----END PGP SIGNATURE-----
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com