Note: several of the commands and directory structures used in this document are specific to Debian GNU/Linux. These are noted in the text. RPM-based system equivalents are provided where known.
You can usually kill an X session with the key combination <ctrl><alt><backspace>. For a managed (xdm, gdm, wdm, kdm, etc.) X session, this usually just restarts the session manager, which can be spectacular, but isn't particularly useful.
You can usually switch to an alternate virtual console, VC, sometimes called a virtual terminal, VT. Preferably one with a command-line login prompt. Use the key combination <ctrl><alt>F[1-6] -- where F[1-6] represents any of the function keys numbered F1-F6 (from X, either left or right <alt> key works, at console, you must use <left alt>). A default Debian GNU/Linux installation runs a getty (terminal login) on the first six VCs. You can also use the chvt command, though this assumes a command line, which you didn't have in the first place, eh? Note that you can issue chvt command remotely, in the event your console is hosed, but your system is still responsive, and you have network access to the machine.
Magic Sysrq
If neither of the above work, and you have compiled it into your kernel, the magic-sysrq key combinations may at least allow you to cleanly shut down your system. Documentation for this is in
/usr/doc/doc/kernel-doc-version/Documentation/sysrq.txt.gz
Essentials:
-
On x86 you press the key combo 'ALT-SysRQ-command key'. Note - Some (older?) may not have a key labeled 'SysRQ'. The 'SysRQ' key is also known as the 'Print Screen' key. For other architectures, YMMV.
-
Of the command keys:
'r' Turns off keyboard raw mode and sets it to XLATE. This is useful for crashed X sessions. 'k' Kills all programs on the current virtual console. Ditto. 'e' Send a SIGTERM to all processes, except for init. 'i' Send a SIGKILL to all processes, except for init. 's' Will attempt to sync all mounted filesystems. 'u' Will attempt to remount all mounted filesystems read-only. 'b' Will immediately reboot the system without syncing or unmounting your disks.
Issuing these in sequence (r k e i s u b) should cleanly shut down your system. Note that you may never regain console display, though sometimes issuing commands (for me, usually a console login followed by attempting to mount a floppy) should give some indication of whether or not the system is responsive.
You don't want to run an XDM login session?
The following commands are largely Debian GNU/Linux specific. Where RPM system equivalents are known, they're given.
To disable xdm for the current system session:
$ /etc/init.d/xdm stopRPM:
These systems usually launch the X display manager from inittab, meaning you've got to change your runlevel. Typically init 2 is non-X and init 3 is the default, X-enabled, runlevel. I think.
To disable xdm startups for *all* system sessions:
$ /usr/bin/update-rc.d -f xdm removeUnder RPM systems, use the chkconfig utility. man chkconfig for more info.
To allow remote xdm control but disable local control: comment out the localhost display in /etc/X11/xdm/Xservers, e.g.:
$ mv /etc/X11/xdm/Xservers /etc/X11/xdm/Xservers.bak &&
sed -e '/^[ ]*:[0-9] local/s/^/# /' < /etc/X11/xdm/Xservers.bak \ > /etc/X11/xdm/XserversUnder RPM: Not sure. I'd appreciate the heads up on where this is located, but you'll likely find it under /etc/X11/ someplace.
To remove xdm from your system:
$ apt-get remove xdmRPM:
$ rpm -e xdm
Managing X overall has gotten a lot better, and I now typically do run a display manager (partial toward WDM and KDM myself) on systems. However, they still can cause problems, including:
- Complicating the X initialization sequence, making debugging and troubleshooting more difficult.
- Your system is incurring the overhead of running an X session when you explicitly aren't using the console (though you may be using the system remotely or in batch processing). This is a waste of resources.
- Though xdm does simplify remote X sessions to an extent, it is an insecure means of accessing your system, and leaves your entire X session open on the wire for snooping. Tunneling through SSH, or another remote access method such as VNC or NX is better except under known secure environments.
Yes, you can run an X display manager such as XDM, GDM, KDM, WDM, etc., and many people do. You've got the option not to, though.
An alternative X startup method is:
$ startx -- :1 1>.startx.log 2>&1 & exitRPM: This may or may not work on your system, depending on how the X startup scripts are parsed. I'd appreciate feedback from a current RPM-based system user.
...executed from a console login. This startx X (on display :1 rather than :0 -- if I do want to run an X display, it won't interfere), logs all X server output to the file .startx.log, including error output (useful for diagnosing problems), and exits the console session. It's generally a good idea not to leave unattended console logins on any system to which others may have access. There's a strong tendency to forget about them.
Home
mail: kmself@ix.netcom.com
Last updated 2005/04/08 10:28:39