Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

On occasion, my laptop has become stuck so I've used the magic key combination of Alt + SysRq + REISUB to perform a safe reboot. However, it doesn't seem to work for me as when I press the B key to complete the magic key command it simply says, "resetting..." and doesn't do anything.

All of the other keys seem to work fine as it resets the keyboard layout, kills all tasks etc., but it doesn't seem to complete with a reboot.

I was under the impression that my laptop should reboot after the magic keys have all been pressed in the order of REISUB.

share|improve this question

5 Answers 5

up vote 24 down vote accepted

Alt+SysRq has been disabled to fix a bug. The disabling of Magic-SysRq was considered a bug itself and it has since been re-enabled (#1025467). If it is still disabled for you, you can re-enable it:

Ubuntu 12.04 and older

Edit the file /etc/sysctl.conf to include the line

kernel.sysrq=1

Ubuntu 12.10 and newer

Starting with Ubuntu 12.10 a more fine-grained control of which Magic-SysRq features are enabled is possible. Just edit the file /etc/sysctl.d/10-magic-sysrq.conf.

The file is well documented and tells you exactly how to enable which features. The current default was picked for security purposes and should only be changed if you know why you need to (for security implications see #194676).

share|improve this answer
    
Thanks, wasn't aware of that. –  James Dec 15 '10 at 17:45
6  
No it hasn't. It works just fine on maverick, natty, oneiric, and precise. –  psusi Mar 8 '12 at 3:59
1  
@geezanansa You can edit your comments while they're still hot. Please avoid adding multiple consecutive comments. Also, SysRq works for me on 13.04. Never tried it on a Live DVD, only after installation though. So, I don't understand the upvotes of this answer because it's about a very short period period in time (see the bug report). ;) –  gertvdijk Aug 17 '13 at 22:38
1  
@gertvdijk: When I updated the question I mentioned etc/sysctl.d/10-magic-sysrq.conf which includes the sysrq parameters for everything you need to enable all respective functions. Back when the question was asked (in 2010), it was actually the solution because "b" was actually deactivated by default due to a bug. I changed the answer to be more general on purpose, I answer the question of sysrq being completely disfunctional and also partly disfunctional. –  mniess Aug 20 '13 at 13:21
1  
@geezanansa, yes, I think they disabled it in quantal, after I posted that –  psusi Aug 20 '13 at 19:41

Keyboards are the issue here!

  • Some just don't like the 4-keys-down at the same time and just stop being a keyboard until you release some.
  • All keyboards turn into QWERTY layout when you send the SysRq signal. This makes it hard to find the right commands on keyboards with another layout. Wikipedia: SysRq commands shows a table to find the right ones for common alternative layouts.
  • Some have SysRq on another key than PrtSc to hold with a function key. On my laptop this is Fn+End. Holding Alt + PrtSc only works if some system process (window manager?) translates it for me. On total crash, only the real SysRq works!
  • Some only trigger SysRq key once you hold the right Alt + PrtSc (by hardware). The left Alt-key won't work in such a case, for the same reason as above. This is how my USB keyboard works.
  • Tip: try out hitting Shift + Alt + SysRq to see a 'help' output on a virtual terminal. This is useful to see if it's working without doing any harm:

    SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

In all cases I've come across it didn't work, swapping the keyboard worked perfectly and showed that nothing was wrong with any kernel setting.

share|improve this answer
    
@geezanansa I've seen keyboard clearly unable to handle certain 4-key combinations. Replacing it solved the issue. Really. It may work for all of your keyboards, though. And if you don't understand the upvotes, then why don't you explain why you don't? –  gertvdijk Aug 17 '13 at 22:37
    
Considering James confirms all sysrq commands work with the exception of B. This answer is not an answer to the question which i read as Why does sysrq B not work? Key board is not the issue for James or many others regarding sysrq. -1 –  geezanansa Aug 21 '13 at 21:20

I ran into this the other day and it took a few seconds to work. I may have even done the entire REISUB sequence twice.

Also, make sure you're using the sysrq key (most laptops will require you to hold down function, so you're really holding down 4 keys at once)

share|improve this answer
    
Thanks for your reply Scott. I do indeed have to hold down the function key (fn) along with alt and sysrq. Once I press the final B key to finish the REISUB sequence my laptop seems to lockup after it displays: Resetting As going through the magic key sequence again doesn't do anything, nor is anything displayed on screen after. So it looks like the system locks up when it's meant to reboot. –  James Nov 2 '10 at 21:26

A few years back I used to use Alt+SysRq+S,U,B,O to reboot or power off a stuck machine, because like for you, Alt+SysRq+B sometimes didn't want to work.

(Also, I need to get into the habit of using Alt+SysRq+E,I first. I don't see much point of using Alt+SysRq+R, since why does keyboard mode matter if it's going to reboot and reset it anyway?)

share|improve this answer
1  
why does keyboard mode matter if it's going to reboot and reset it anyway? Because it gives back input capability to keyboard? which might mean you do not need to reboot or power off –  geezanansa Aug 19 '13 at 2:21

ATTRIBUTIONS:
https://fedoraproject.org/wiki/QA/Sysrq#How_do_I_use_the_magic_SysRq_key which was based on the original work by
Credits
Written by Mydraal
Updated by Adam Sulmicki
Updated by Jeremy M. Dolan 2001/01/28 10:15:59
Added to by Crutcher Dunnavant

http://askubuntu.com/a/11194/102029 mneiss provided links for LaunchPad.

Contents

What is sysrq?
Why does RESIUB(O) not work?

1 How do I get sysrq to behave the way I want?
1.1 What is the magic SysRq key?
1.2 How do I enable the magic SysRq key?
1.3 How do I use the magic SysRq key?
1.4 What are the 'command' keys?
1.5 Okay, so what can I use them for?

1.6 Troubleshoot

1.6.1 Hanging before initscripts get run
1.6.2 Sometimes SysRq seems to get 'stuck' after using it, what can I do?
1.6.3 I hit SysRq, but nothing seems to happen, what's wrong?
1.6.4 I want to add SysRQ key events to a module, how does it work?
1.6.5 Conclusion
1.6.6 APPENDIX
Note.
You may find using Ctrl + F to use the Table of Contents helpful.

What is SysRq?

A common well known and used method of regaining use of machine after it freezing or locking with limitising the risk of disk corruption leading to system file damage or loss of data is to use
Alt + SysRq + r and then s and then e and then i and then u and then b and/or if needed (o)

This has not been working as expected for many (ie myself and James) through all flavours from >= 8.04LTS to current 13.04 release.

Why does RESIUB(O) not work?

Consider this bug description found at LaunchPad Bug 194676:

Description of the problem:
By default SysRq is enabled by default on Ubuntu desktop systems which is invaluable when a system has locked up and you want to stop it as gently as possible or debug the issue. However many people are surprised that you can also ask it to dump the contents of current memory to the console (or dmesg) albeit only from the keyboard.
openSUSE sets a default bitmask of 176 on its SysRq that by default restricts you to sync, reboot and "remount read-only". This stops people using sysrq by default to inspect memory which sounds sensible.

Ubuntu Developers saw the need to do something about this and the best solution considering the possible complications of the mentioned observation is to apply bitmask 176 sysrq by default creating the need for user input to set sysrq as they desire. Bitmask 176 only allows S, U, B which is sync, remount mounted partitions and reboot.
Reading the full bug report and comments will highlight some options that may be applicable to your system.

The accumulative affect of different hardware, kernels, keyboards and bitmasks mean sysrq is behaving differently for different people.

One method of getting txt output regarding how your system is using sysrq is to apply sysrq commands from tty (when system not suffering from locks/freezes). Doing this may indicate sysrq has not been completely disabled but is using bitmask 176.

Searching for /proc/sys/kernel/sysrq on a 13.04 Desktop amd64 liveDVD and an 13.04 Desktop amd64 install confirms the default is currently to leave sysrq at bitmask 176.

If sysrq does work for you; it may be worth asking, "If i did not change 10-magic-sysrq settings then; Who did.?"

1 How do I get sysrq to behave the way I want?

What follows is an edited copy and paste of https://fedoraproject.org/wiki/QA/Sysrq.

1.1 What is the magic SysRq key?

It is a 'magical' key combo you can hit which the kernel will respond to regardless of whatever else it is doing, unless it is completely locked up.

1.2 How do I enable the magic SysRq key?

sysrq is built into Ubuntu kernel but is disabled at boot time, by default, using 10-magic-sysrq.conf.

To re-enable it at boot time, you have to edit /etc/sysctl.d/10-magic-sysrq.conf file. ie uncommenting this line will enable all functions of sysrq:

#   1 - enable all functions of sysrq

When running a kernel with SysRq compiled in, /proc/sys/kernel/sysrq controls the functions allowed to be invoked via the SysRq key. Here is the list of possible values in /proc/sys/kernel/sysrq:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function description):
    2 - enable control of console logging level
    4 - enable control of keyboard (SAK, unraw)
    8 - enable debugging dumps of processes etc.
    16 - enable sync command
    32 - enable remount read-only
    64 - enable signalling of processes (term, kill, oom-kill)
    128 - allow reboot/poweroff
    176 - allow only sync, reboot and "remount read-only"
    256 - allow nicing of all RT tasks 

You can set the value in the file by the following command.

echo "number" >/proc/sys/kernel/sysrq

So to fully enable it would be.

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

Or also can enable it by doing.

sysctl -w kernel.sysrq=1  

Note.
The value of /proc/sys/kernel/sysrq influences only the invocation via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always allowed (by a user with admin privileges-see below).

1.3 How do I use the magic SysRq key?

Ubuntu Desktop

You press the key combo Alt + SysRq + command key.

N.B.- See the notes in this section and in the Troubleshooting section for other possible default settings for other systems and keyboards.

It is possible to set any character of your choosing:All Architectures

Write a character to /proc/sysrq-trigger:

echo t > /proc/sysrq-trigger

would set the T behave as SysRq
Note.
Some keyboards may not have a key labeled SysRq. The SysRq key is also known as the Print Screen key. Also some keyboards cannot handle so many keys being pressed at the same time, so you might have better luck with Alt + SysRq - SysRq then press command key then release everything. See the full writing of QA which this guide is based on https://fedoraproject.org/wiki/QA/Sysrq#How_do_I_use_the_magic_SysRq_key.3F for more information regarding this.

1.4 What are the 'command' keys?

'b' - Will immediately reboot the system without syncing or unmounting your disks.
'c' - Will perform a kexec reboot in order to take a crashdump.
'd' - Shows all locks that are held.
'e' - Send a SIGTERM to all processes, except for init.
'f' - Will call oom_kill to kill a memory hog process.
'g' - Used by kgdb on ppc and sh platforms.
'h' - Will display help (any key that is not listed here will bring forth help )
'i' - Send a SIGKILL to all processes, except for init.
'k' - Secure Access Key (SAK) Kills all programs on the current virtual terminal.  

Note.
See important comments below in SAK section.

'l' - Shows a stack backtrace for all active CPUs.
'm' - Will dump current memory info to your console.
'n' - Used to make RT tasks nice-able
'o' - Will shut your system off (if configured and supported).
'p' - Will dump the current registers and flags to your console.
'q' - Will dump a list of all running timers.
'r' - Turns off keyboard raw mode and sets it to XLATE.
's' - Will attempt to sync all mounted filesystems.
't' - Will dump a list of current tasks and their information to your console.
'u' - Will attempt to remount all mounted filesystems read-only.
'v' - Dumps Voyager SMP processor info to your console.
'w' - Dumps tasks that are in uninterruptable (blocked) state.
'x' - Used by xmon interface on ppc/powerpc platforms.
'0'-'9' - Sets the console log level, controlling which kernel messages will be printed to your console. ('0', for example would make it so that only emergency messages like PANICs or OOPSes would make it to your console.) 

1.5 Okay, so what can I use them for?

Unraw is very handy when your X server or a svgalib program crashes.

Sak (Secure Access Key) is useful when you want to be sure there is no trojan program running at console which could grab your password when you would try to login. It will kill all programs on given console, thus letting you make sure that the login prompt you see is actually the one from init, not some trojan program. Others find it useful as (System Attention Key) which is useful when you want to exit a program that will not let you switch consoles. (For example, X or a svgalib program.)
Note.
In its true form it is not a true SAK like the one in a c2 compliant system, and it should not be mistaken as such.

Reboot is good when you're unable to shut down.
Note.
It's general considered a good practice to umount first

Crashdump can be used to manually trigger a crashdump when the system is hung.
Note.
The kernel needs to have been built with CONFIG_KEXEC enabled!

Sync is great when your system is locked up, it allows you to sync your disks and will certainly lessen the chance of data loss and fscking.
Warning
The sync hasn't taken place until you see the "OK" and "Done" appear on the screen. (If the kernel is really in strife, you may not ever get the OK or Done message.

Umount is basically useful in the same ways as Sync.

The loglevels 0-9 are useful when your console is being flooded with kernel messages you do not want to see. Selecting 0 will prevent all but the most urgent kernel messages from reaching your console.
Note.
They will still be logged if syslogd/klogd are alive

Term and kill are useful if you have some sort of runaway process you are unable to kill any other way, especially if it's spawning other processes.
Note.
When experiencing bad kernel panic do Alt+Sysrq+e then Alt+Sysrq+u then Alt+Sysrq+i and finally Alt+Sysrq+b

1.6 Troubleshoot

1.6.1 Hanging before initscripts get run

If the machine is hanging before the initscripts get to run, boot with sysrq_always_enabled=1

1.6.2 Sometimes SysRq seems to get 'stuck' after using it, what can I do?

Tapping shift, alt, and control on both sides of the keyboard, and hitting an invalid sysrq sequence again will fix the problem. (i.e., something like alt+sysrq+z).

Switching to another virtual console (Ctrl+Alt+Fn1-Fn6) and then back again Ctrl+Alt+Fn7 should also help.

1.6.3 I hit SysRq, but nothing seems to happen, what's wrong?

There are some keyboards that send different scancodes for SysRq than the pre-defined 0x54. So if SysRq doesn't work out of the box for a certain keyboard, run showkey -s to find out the proper scancode sequence. Then use setkeycodes <sequence> 84 to define this sequence to the usual SysRq code (84 is decimal for 0x54). It's probably best to put this command in a boot script.
Warning
You exit showkey by not typing anything for ten seconds.

1.6.4 I want to add SysRq key events to a module, how does it work?

In order to register a basic function with the table, you must first include the header include/linux/sysrq.h, this will define everything else you need. Next, you must create a sysrq_key_op struct, and populate it with...

  • The key handler function you will use.

  • A help_msg string, that will print when SysRQ prints help

  • An action_msg string, that will print right before your handler is called. Your handler must conform to the prototype in 'sysrq.h'

After the sysrq_key_op is created, you can call the kernel function register_sysrq_key(int key, struct sysrq_key_op *op_p); this will register the operation pointed to by 'op_p' at table key 'key', if that slot in the table is blank. At module unload time, you must call the function unregister_sysrq_key(int key, struct sysrq_key_op *op_p), which will remove the key op pointed to by 'op_p' from the key 'key', if and only if it is currently registered in that slot. This is in case the slot has been overwritten since you registered it.

The Magic SysRq system works by registering key operations against a key op lookup table, which is defined in 'drivers/char/sysrq.c'. This key table has a number of operations registered into it at compile time, but is mutable, and 2 functions are exported for interface to it the register_sysrq_key and unregister_sysrq_key. Of course, never ever leave an invalid pointer in the table. ie; when your module that called register_sysrq_key() exits, it must call unregister_sysrq_key() to clean up the sysrq key table entry that it used.
Note.
Null pointers in the table are always safe.

If for some reason you feel the need to call the handle_sysrq function from within a function called by handle_sysrq, you must be aware that you are in a lock (you are also in an interrupt handler, which means don't sleep!), so you must call __handle_sysrq_nolock instead.

1.6.5 Conclusion

Use Alt + SysRq + S and then U and then B to sync, attempt to remount all mounted filesystems and then reboot if needed. Without changing a thing to system files.
If Alt + SysRq + B does not reboot system it may be necessary to edit /etc/sysctl.d/10-magic-sysrq.conf in order to allow the attempt of applying Alt + SysRq + B (or/and O after editing /proc/sys/kernel/sysrq bitmask to enable the reboot and shutting down of the system by use of sysrq. You could do this by any of the methods described above.

1.6.6 APPENDIX: See also - http://ubuntuforums.org/showthread.php?t=617349 and https://www.kernel.org/doc/Documentation/sysrq.txt

For those with Apple MacBook keyboard troubles regarding sysrq see: https://help.ubuntu.com/community/AppleKeyboard and https://bugs.launchpad.net/mactel-support/+bug/262408

Relative interesting info-After watching 17 08 2013 episode of the BBC programme "Click" and the "cyberwarfare" article really caught my attention. The programme also have their own website Click if you can not watch the programme. FAWC

share|improve this answer
2  
In particular, I just tested Al+SysRq+REISUB on a fully updated Quantal i386 system and it works fine. Are you sure the linked security bug, or any part of the discussion of security in this answer, is really related to the problem? If so, is it a common enough cause of the problem that it should appear first in this answer? –  Eliah Kagan Aug 19 '13 at 3:49
    
The security issue is important as full set of sysrq commands are not available due to bitmask 176 being applied at boot time; as the Bug report describes. –  geezanansa Aug 21 '13 at 21:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.