> When X freezes, there's no a priori reason why anything should be logged. > The rest of the machine should be running normally, and the best course > of action is to telnet in through the network or a serial line and kill > the X session (using startx it'll be an xinit process).
This wasn't an X freeze; it was the whole machine. I found it while telnetting in; when I got there, X was frozen, and I couldn't get to a VC. > On the other hand, kernel panics are different and may or may not be logged, > depending on whether it's safe. It will normally tell you if the disks > have not been synced (though I've only witnessed that on a VC, not in X), > in which case you might as well cycle the power. It didn't sync the disks, so we got to wait while it e2fsck'd a pair of 4G drives (*sigh* at least the third disk had been disconnected. I need to poke around and figure out how to get it to do the two scsi drives simultaneously . . .). So how *do* you figure out why a machine crashed? I've never seen one before where I couldn't immediately figure out which hardware did it . . . rick -- These opinions will not be those of ISU until it pays my retainer.
