Anders Rayner-Karlsson wrote:
* Giancarlo Niccolai <gc(a)falconpl.org> [20090331 12:20]:
> it may be educated enough to try it. But it is not like that an X
> session hang so bad that you have to ctrl-alt-bs it will allow you to
> CAF1-6 at all, or will let you to do anything meaningful with it (i.e.
> bash may not be able to get the resources to start). When you HAVE to
> CABs, it's because you CAN'T CAF1-6.
>
> (There was my two cents, so don't expect me to join in this convo; I
> just wanted to correct your assumption that you may CAF1-6 away a
> situation in which you have to CABs, which is wrong, as another poster
> pointed out).
IIRC, and I believe that was pointed out in this thread as well, is
that these keypresses are handled in the same way by the same part of
the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
Not quite. It
does so often, but not always, because when C-A-Fn is
pressed, some memory ( ... file descriptors, inodes etc.) needs to be
allocated and be swapped around to launch a console.
In case of heavy "memory-hog races", this can easily fail or it may take
a long time.
Through past experience, I have never found an instance (since
moving
from XFree86 to Xorg) where the Xserver was wedged in a way that
switching to a vc did not work, but C-A-Bs did.
I've been in such situations
many times ;)
I have seen plenty of
X lockups (Xorg intel driver issues in F10) in the last few months and
not a single one of those were resolvable by C-A-Bs.
Try a classical multi-user
workstation-pools setup with "C-A-F<N>"
disabled - Then, there is no C-A-Fn to press, while a C-A-BS would
simply kill the user's logging and bring him back to his login.
Another case where this does't work is when switching from "x-terminal"
to console leaves the console in some unusable state (e.g. when pressing
C-A-Fn come up with a "black screen" or with a "fly-dirt screen"
because
of some bugs some where).
Ralf