DJA wrote: > James G. Sack (jim) wrote: >> [EMAIL PROTECTED] wrote: >>> It freezes X and therefore the keyboard and therefore necessitates a >>> reboot. >> >> WARNING: Keyboard frozen detected. Press any key to continue. >> >> Hmmm, I don't quite understand the details, but I've found that keyboard >> frozen sometimes just means that X (or an X-app) is not playing nice -- >> not necessarily that keyboard input has stopped. I guess it's the order >> of handlers in the keyboard chain. Things I try before pulling the >> switch are, in order: >> >> ctrl-alt-f1 (login and kill apps & X and/or telinit 1 then telinit 5) >> ctrl-backspace (shutdown X (session?)) >> alt-sysreq S, alt-sysreq U, alt-sysreq B (sync, umount, boot) >> >> If the first one works, that would seem to cause the minimum disruption. >> The second is well known, and AFAIK it unceremoniously kills apps. >> The third one tries to avoid filesystem problems. >> >> Regards, >> ..jim > > Shouldn't SSH be in that list somewhere? >
Thank you! ssh should come second, I suppose, but involve about the same activities as the first. In some cases, keyboard response can be better via ssh connection than in a vc -- eg, a vc might popup but seem not to allow login (or be flooded w/ syslog message spam). BTW, I failed to say that if I can get a VC (or ssh) login, the first thing I look at is dmesg. Then the apps-shutdown sequence is kind of subjective, but my order is plugins and pluginhelpers, browsers and email, then other suspects that seem appropriate at the time, then X. Maybe others have some suggestions for improving this. I really don't have a precise definition of shutting down X. I often end up toggling runlevel to recover. I suppose that's not much different from rebooting, as far as apps are concerned. I don't know any authoritative justification for the above procedures -- it's just what I have sometimes found useful. Regards, ..jim -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
