I found the solution myself just after asking this question.
To switch back the console in which X is running (usually tty7), from ASCII mode to RAW mode execute the following command:
sudo kbd_mode -s -C /dev/tty7
And now everything works as expected again. :)
More information available in the question: What does raw/unraw keyboard mode mean?
When you press a key on your keyboard, it sends a numeric code to the computer, called a scan code. The scan code tells the computer which key was pressed; for example, on a typical US keyboard, the A key sends the scan code 30 when you press it (and 158 when you release it). The keyboard driver reports these codes directly to applications when the keyboard ...
Most laptops require pressing Fn to get the SysRq key. Pressing Fn usually doesn't affect the Alt key (at least the left one) but may affect the letter that you press after SysRq. Fortunately, you don't need to press SysRq and the third key together, it's enough to hold Alt down. The following sequence works on all the laptops I've seen:
Press and hold Alt.
You can define which type of code your keyboard sends. This is done via the keyboard mode. You can change the mode of a keyboard with kbd_mode.
These are the options from the manpage:
-s: scancode mode (RAW),
-k: keycode mode (MEDIUMRAW),
-a: ASCII mode (XLATE),
-u: UTF-8 mode (UNICODE).
Its much easier for a developer to catch key events like ...
The magic SysRq key itself is AltSysRq or AltPrint Screen on PCs, which is in turn combined with a third key (letter), indicating some specific action.
The short version is that, at a console, AltSysRqSpace will display the available shortcuts (thanks to Josip Rodin for pointing that out).
The magic SysRq key, if enabled, is controlled by /proc/sys/kernel/...
Assuming you have a kernel with the debugger option compiled in you can use ControlAltEscape. From there you can call boot(0) or panic.
Chapter 10 of the FreeBSD developers handbook explains this in a lot more detail.
So much for more or less the same as SysReq via a keyboard. On the serial console, you need to send the break signal and have the options ...
This should work if sysrq is enabled in the kernel (tested live on my machine):
# echo "h" > /proc/sysrq-trigger
Requires root access.
The SysRq keys are not regular keys handled by X, thus xdotool can't trigger the magic keys because it interacts with Xorg itself, not the kernel. Thankfully the kernel provides a special file to trigger them from ...
Forget about REISUB. I don't know who invented this, but it's overly complicated: half the steps are junk. If you're going to unmount and reboot, you only need two steps: U and B. At most three steps E, U, B.
Alt+SysRq+R resets the keyboard mode to cooked mode (where typing a character inserts that character). That's useful if a program died and left the ...
I don't think Ctrl+PrtScr will do much, what you need is SysRq (usually on the same physical key as PrtScr, accessed by holding Alt when pressing that key, for that reason it's a little unclear to be if the "magic" combinations are actually SysRq+<letter> or Alt+SysRq+<letter>).
The B function will boot the system, so your combination is a ...
The documentation for sysrq is in the linux source code (https://github.com/torvalds/linux/blob/master/Documentation/sysrq.txt).
I very highly recommend that you read it.
Is SysRq key enabled?
First, please ensure that the use of the magic SysRq key is enabled:
$ cat /proc/sys/kernel/sysrq
If it says 0 then SysRq is disabled. You can enable it with:
The default Arch Kernel should have the sysrq feature enabled in kernel (I'm using a custom one, but based the config on the default one). However, in the default kernel, the bitmask to control, which features of the sysrq keys are usable, is set to 0. I believe it is set to 16 (10000) somewhere during the boot on Arch, but I'm not sure where.
Provided the ...
The problem is not in software, it's in hardware.
Keyboard keys are not independent: there're about 100 keys, but only about 26 wires going into keyboard's internal controller:
(Image from dreamstime.com)
This means that not all keys can be detected when simultaneously pressed. Because RAlt is much closer to SysRq than LAlt, I always use it to free one ...
Is there a specific reason as to why it works as non-root from a keyboard but only as root from a console?
As far as I understand, the SysRQ magic sequence is handled at a very low level, which doesn't know whether the user on the console is root or not. In fact, it works even when no users are logged in and even while booting.
If an intruder or someone ...
In the linux kernel source code in sysrq.c at line 415, there is a struct defined, what should happen when a certain key is pressed. So you see, no command in a terminal is excuted, instead of this, hard coded functions in the kernel are called. So, as long as the kernel is not crashed, you can press those keys, doesn't matter which application is running in ...
On a typical laptop, you need to press the Fn key to press SysRq. If you also press the letter in the same movement, you end up pressing Fn+Alt+SysRq+letter. But several letters are mapped to numeric keypad keys when combined with Fn. For example, if you try to press Alt+SysRq+U, you end up pressing Alt+SysRq+Num4 instead.
To avoid this pitfall, press and ...
From the Kernel section on the Arch Linux Keyboard shortcuts wiki page
If you wish to have it enabled during boot, edit /etc/sysctl.d/99-sysctl.conf and insert the text kernel.sysrq = 1. If you want to make sure it will be enabled even before the partitions are mounted and in the initrd, then add sysrq_always_enabled=1 to your kernel boot command line ...
You can't directly get the response to be shown to the ssh terminal, but the kernel's output is recorded in dmesg (and usually /var/log/messages too); so you can echo h > /proc/sysrq-trigger; dmesg | tail to see what was printed.
You can hook a script into Alt+SysRq if you modify the kernel sources. The Alt+SysRq handling is defined in drivers/tty/sysrq.c. For instance, Alt+SysRq+f calls the sysrq_handle_moom() function that schedules a call of out_of_memory() to kill a process.
static void moom_callback(struct work_struct *ignored)
/* ... */
Apparently, it can be enabled/disabled using /proc/sys/kernel/sysrq if the kernel supports it, i.e., CONFIG_MAGIC_SYSRQ is enabled in the kernel config what should be the case for Slackware, according to this.
as linked in the wikipedia article in external links ... you can see that documentation here: Linux Magic System Request Key Hacks
this is also found in Linux kernel source under the Documentation subdirectory
Generally, local access to a Linux machine is considered a sign that it's your system. Consider "presence" as a form of authentication. Once you're logged in, the shell doesn't (by itself) know where you came from.
The default permissions of most Linux distributions reflect this. If your system is in a computer lab or some other similar situation, you may ...
I was curious to see if you could inject the SysRq keypress using the Linux uinput device, so I added some code to another small project and it seems to be possible. But as was already noted, of course you need to have root access for this as well.
For this particular key combination, I'd have to execute:
./sendevtkeys /dev/uinput 56 99 35
where 56 ...
Yes, this is possible, at least from NoVNC with KVM based guest. The trick is to understand that VNC has been built for X11. Hence, on the wire, the keycodes you need to send are the one used internally by X11.
In this specific use case, this is:
0xffe9 --> alt
0xff15 --> sysrq
0x0062 --> b
VNC protocol specification, section 6.4.4 page ...
You might not want to have the ability for some random person to walk up to the keyboard and reset the machine, or even worse, start printing registers, syslog or all tasks to the console, all without logging in. Its a potential security issue.
I selectively enable it, for example, on hardware in our datacenter hooked up to a serial console concentrator. ...
The SysRq direct function only works on the console.
On a standard "VGA" console this is the literal key SysRq (sometimes marked Print Screen) in conjunction with Alt and "command".
On a serial console this can be accessed via the BREAK signal.
However, over SSH there is no direct access to SysRq and you have to use the /proc/sysrq-trigger file instead.
There is kernel boot parameter sysrq_always_enabled according to the doc:
Ignore sysrq setting - this boot parameter will
neutralize any effect of /proc/sys/kernel/sysrq.
Useful for debugging.
I have tested Sysrq to work(eg. help,sync) even when kernel.sysctl=0 (so it's just as ...
What are the details of this and is it true to say that Linux is less resilient that MS-Windows in this case?
It might have been useful to make the comparison at one point. That comparison probably explains why these SysRQ commands are quite so well known. However it does not apply in comparing recent Linux and Windows versions.
The details are largely ...
I'm guessing your underlying question is how to make sure that the memory information has been logged by the time you copy the system log...
I haven't checked the code but I think it's all asynchronous. If you want to serialise operations you can do so by writing to /dev/kmsg; anything you write there ends up in the kernel buffer. So something like
echo m &...
If you are kernel development you could have sudden kernel panic, SysRq key will be very valuable. The magic SysRq key is a key combination in the Linux kernel which allows the user to perform various low level commands regardless of the system’s state.
normally when you do Alt+SysRQ+b system reboots without umounting or sync
This command is often used to ...