I foolishly started a job that turned out to be so big and busy that it froze everything. I wish I could type a kill command or use xkill, but the system is unresponsive, apart from the audible swapping. On Windows, Ctrl+Alt+Del helps in these situations; does Linux has a way to knock through into an overloaded system?
Just saw this one and couldn't stop myself from sharing:
Ctrl + Alt + F4 opens a console window, where you can login and kill stuff as necessary or reboot the system. Use Ctrl + Alt + F2 or Ctrl + Alt + F1 to go back.
In some cases you can restart the gnome session by pressing Alt + F2, and the R in the window that opens. This should leave all programs running, but gnome itself will restart, so if the issue is in gnome it may help.
If the above don't help, you can do a warm reboot, by pressing the following key sequence:
While keeping pressed down both the Alt and Print Screen keys, sequentially (one by one) press the keys:
R E I S U B
This will sync and unmount the file system and do a safe reboot. The keys have the following meaning:
Finally, if all else fails, keep the power-on button pressed for a few seconds to force a cold reboot, or take the power cable/battery out ;-).
SysRq incantations.
F, which invokes the OOM killer, before sending any other signal to all processes. Many times I've recovered from a stray, memory hogging process without losing my current session.
Alt and Print Screen keys, ..." - You don't need to hold down Print Screen while doing the other keys! Just hold down Alt, and then press, in sequence, Print Screen, R, E, etc. Much easier. Also consider SysRq+K, which will kill all processes on the current virtual terminal. You'd lose your graphical session, including hopefully your runaway process, but not the system. (I'm not 100% sure SysRq+K still works as expected with Wayland, never tried it)
Depending on your installation and environment, you may be able to kill or restart the entire XOrg session with Ctrl-AltBackspace, but some modern distributions have been disabling that shortcut by default, unfortunately.
If your virtual terminal service is still working (typically getty or something similar), you may be able to switch to an alternate local console with e. g. LAlt-F1, and log in there to issue kill commands at a CLI shell if the system is not so bogged down that you cannot even log in.
If you are on a network and your host has a running secure shell daemon, you might also be able to log in through ssh to kill your processes that way.
DontZap unfortunate, since that keystroke is wired into my fingers as backward-kill-sexp. It's horrendous when simply deleting some code kills the entire X session.
gdm, XOrg will restart and deposit you at the login dialog. It will be true if you started the GUI session yourself from a console login however. Unless your shell was startx or something. 'Unfortunate' here is, as it usually is, in the eye of the beholder (:
exec startx to have the shell terminate when startx terminates.
For the specific case of swapping, what you want to do is to invoke the out-of-memory killer.
This can be done with the SysRq key combination Alt+SysRq+F. It will stop the process that is most heavily allocating RAM.
However, the key combination is by default disabled on many systems such as Ubuntu because it can potentially enable to circumvent screen lock. It can be enabled by editing /etc/sysctl.d/10-magic-sysrq.conf.
You can have your init daemon invoke any (previously configured) program of your choosing by pressing Alt+↑ at a console, which will send SIGWINCH to process 1. The keyboard must not be in raw mode, which means this will not work under an X session without pressing Alt+SysRq+R first (which will work assuming the magic SysRq key has been enabled).
In a systemd-based system, the action to take is configured by defining a unit called kbrequest.target; see systemd.special(7).
Under sysvinit, this is configured by an /etc/inittab entry starting with ::kbrequest:; see inittab(5).
Other init systems may have different ways to configure how they react to this key combination.
Im a little surprised that no-one has mentioned the problem, rather than the fix. The issue is that your machine shouldn't (ideally) be unresponsive when under memory pressure. This is a problem with the current swap strategy, and has come up in kernel discussions previously, as the "elephant in the room".
There are user-space "fixes" which help mitigate the problem. I recommend something like earlyoom, which will kill processes before you run out of ram, preventing the swap problem in the first place.
