Paying for Software?

Are you still running Windows? Why not try an entirely free, open, fast, slick and reliable operating system instead?

Ubuntu

Are you still running Internet Explorer? Why not try a free, fast browser that works, with more features than you could shake a hundred sticks at?

Firefox 3

Are you still running Microsoft Office? Why not try a free office suite that looks like and is compatible with Office, but without all the bloat and unusable gimmicks?

Use OpenOffice.org


kb > linux> magickeys

Magic Keys

NB: the Magic Keys should only be used when every other alternative aside from the power button has been tried - see the bottom of the page for more information.

Although Linux is very stable, it isn't perfect, and occasionally you may encounter some form of system freeze. However, there's no need to revert to the ol' Windoze "hard reboot and hope the filesystem's OK" plan. Linux gives us a direct line to the kernel, so we can almost always reboot relatively safely, regardless of what state the system is in.

To see if your kernel has Magic Keys enabled, try

$ cat /proc/sys/kernel/sysrq

A '1' means it's enabled, and a '0' means it's disabled. If it's disabled, you can try enabling it with

$ echo 1 > /proc/sys/kernel/sysrq

To make use of Magic Keys when everything's screwed up, you need the key combination Alt + PrintScreen (more appropriately called Alt + SysRq). You'll need to keep holding down these two keys, whilst you continue to enter the rest of the commands. Type each letter with a couple of seconds in-between each one: R, E, I, S, U, B.

Alt + SysRq + {R E I S U B}

But, you surely won't be happy until you know what each one does, eh?

R - set keyboard mode to XLATE (basically ensures the following will be heard by the kernel)
E - sends a SIGTERM to all processes except init
I - sends a SIGKILL to all processes except init
S - sync all mounted filesystems (flushes the buffers)
U - unmount all filesystems (actually, re-mount as read-only)
B - reboot now!

Clearly, being able to kindly ask all processes to close (SIGTERM), and therefore make any backups or do any cleanup that needs to be done, is highly preferable. However, it's really sync and unmount that do the magic - these ensure that your filesystem is not going to be corrupted on reboot, and won't require fsck (if a system loses power when the filesystems are only mounted in read-only mode, there won't be data sitting in the buffers still waiting to be written to disk; plus, since no data is being written, there can't be any corruption occurring as a result of power-off during a write to disk either).

Many people recommend certain linguistic aids to help remember this sequence, the most common of which tend to be the word 'busier' (REISUB in reverse), and 'Raising Elephants Is So Utterly Boring'. If they help you to remember the sequence, then great. I have in the past found imagining the following sequence of events to be easier:

exit Raw mode, tErminate processes, kIll processes,
Sync data, Unmount drives, reBoot.

Various people advocate various different orderings of the SysRq keys for these circumstances. Personally, I've always used REISUB, and have never encountered a problem. But, of course, this is Linux, and there are many different ways of accomplishing anything. It's your choice...

A quicker solution, should it work, could be to try (Alt + SysRq + R) to set the keyboard mode, and then (Ctrl + Alt + Del) to reboot.

To learn more about SysRq keys, try wikipedia's Magic SysRq key page (which advocates REISUB), or try PmDematagoda's excellent post on ubuntuforums (which advocates RSEIUB). Alternatively, google is your friend.

But remember, before trying the REISUB method on an apparently locked system, you should already have verified that you can't kill the X session with (Ctrl + Alt + Backspace), that you can't switch to another tty with (Ctrl + Alt + F1,F2,F3...) and resolve the problem from there, and that (Ctrl + Alt + Del) to reboot isn't responding either. REISUB should only be used when you've exhausted all other possibilities to resolve the problem or reboot normally, and when your only other alternative is the power button. And, realistically, that doesn't tend to happen too often under Linux - hopefully!

(c) Ace 2008