I don’t agree with that at all. Straight B would be no different that a hard reboot. Whereas following REISUB gives the system a chance at a more graceful shutdown and you might not even need to complete the sequence to gain back control and use systemctl reboot
Just remember this saying Reboot Even If System Utterly Broken
R - switch the keyboard mode
Switch the keyboard from raw mode. chance to help with keyboard driver issues
E - gracefully terminate all running programs
This sends the SIGTERM signal to all processes except init and thereby asks them to gracefully terminate, giving them a chance to tidy up and free their resources, save data, etc…
I - forcibly kill all running programs
This is similar to the E, but sends the SIGKILL signal to all processes except init, which kills them immediately and forcibly.
S - sync all disks and flush their caches
All your disks normally have a write cache, a piece of RAM where the system caches data it wants to save on the device, to speed the access up. Syncing tells the system to flush these caches now and perform all remaining writes. That way you do not lose any data that has already been cached but not been written yet, and it protects from leaving the file system in an inconsistent state.
U - unmount all disks and remount them read-only
makes all mounted disks read-only to prevent any further (partial) writes.
B - reboot the system
This reboots the system. However, it does not perform a clean shutdown, but instead a hard reset.
The last six months or so, things are getting back to “normal” or perhaps the “new normal” for me and time on the forum is limited. Often scanning or skimming posts is the best I can do.
In your mind imagine a 20 yr old running the hurdles in track. A thing of speed and grace. Now in your mind, imagine a 72 yr old person trying to get across the Wal-Mart parking lot with a walker.
Apply the above to reading speed and comprehension.
Modern filesystems are able to handle crashes gracefully
However, trying to write (sync) to a disk while the kernel is in a bad state risks introducing corruption.
That also makes sense to me, but I don’t have expertise nor a stake in this.
Whichever is more true, I think that if you really don’t remember reisub, the single b is still better than holding down to power button. This is honestly more due to my superstition, but when I hold down the power button, my hardware makes a distinct noise when it finally cuts the power. I don’t know if this is true, but it feels likes the power is physically cut, when instead with b it’s the kernel doing a smoother crash landing, and that worrying noise is absent.
There is no cost associated with simply doing the entire REISUB procedure. It takes 5 seconds in total, and if you have to do it so often that there is actually a benefit to saving those 5 seconds, there is something really wrong with your computer anyway.
That’s interesting. Thanks for tracking that down. I’ll have to think on that a little bit. Sounds like it’ll depend on whether the data you’re trying to sync is more important than the risk of kernel corruption. Here’s some of their discussion on it: https://lore.kernel.org/lkml/20190909183817.GB12602@angband.pl/T/#t
Doing R,E,I before B would still be worth it I believe as that’s changing keyboard input and sending term and kill signals to processes. Which, depending on why your system froze may give you enough control to finish with a systemctl reboot. As an example, I had a window manager freeze on me and just doing RE was enough to give control back and allow a normal reboot. Maybe the new mnemonic should be “Reboot Even If Broken” now?
It should take longer than that. You should wait between key presses to give the system time to complete those tasks you’re requesting of it. Especially if you’re trying to sync your disks. Moving and saving data is not instantaneous. Does it take your system 5 seconds to shutdown normally? Specifically, according to the kernel doc a sync hasn’t been completed unless you see OK and Done appear on the screen
One second between each stage of REISUB is usually sufficient on all but the slowest of computers. Since there are 6 keypresses, that means 5 seconds, give or take.
Yeah, if I do not shut down the DE. I bet yours does too, just switch to a TTY and run
shutdown now
Unless it’s a very old computer, it shouldn’t last much longer than 5 seconds.
Agreed! And if one has something important enough to risk corruption, do the good ol’ reisub.
The kernel documentation I linked and discussion linked by @KDen explicitly talk about a cost, namely the cost of a possible corruption with using SU. Just having repaired a corrupted drive, it unfortunately takes more than 5 seconds even if you’re lucky to have your live-usb with you
Maybe I sometimes obsessively try to shave seconds away from rare events (looking at you, my dear vimrc), but then I try to remember, among other life lessons from the same source, the chart by Randall Munroe :
This REISUB helps me a few times. I found it will be fail when I exec libinput debug-events --grab. I do not know how to exit that cmd, Then I tried REISUB. However, this time REISUB not work. so i push power button for a while to shutdown my lattop.
I find a place REISUB will work. I plugin a new screen and setup in display setting. Desktop, keyboard, mouse all froze. I tried plugin usb again and still no mouse and keyboard. Then I tried ssh connected succeedfully. glances shown that Xorg took 100% cpu. Then I trie alt+REI. Desktop restart. ok Thank you again
I have literally just dumped my Logitech MX Keys keyboard for my trusty Filco Majestouch because of this… Yep, it caught me out too, that and the fact that so many keys were missing in favour of stupid ones like calc, and screenshot… Gah!
Hey there! This one is quite strange.
When I do REISUB, my laptop actually reboots…but it can’t find the OS at boot. From there I have to hard-shutdown and then boot it up again. At that point it works.
Seems like REISUB just…I don’t know, temporarily wipe the OS…?
Do you have any idea?
I’m new to this. I’m using the latest version of EOS, Galileo, with KDE 6.0 (it probably doesn’t matter which version I’m using).
But I want to make sure: Maybe my version of EOS has SysRq activated by default? Or do I always have to activate it?
Also, in case I have to activate it, is that still the command to activate it, or has it changed?
Thanks for clarifying this. I thought you just had to press alt+SysRq, release all the keys, and then press “REISUB” one by one, without holding down ALT. But it seems that the ALT key must always be pressed.
I guess it still works the same way today right? In EOS Galileo.
Also, while I do this, a task manager or something similar should not appear like it appears in Windows when I press ctrl+alt+del, right?
Sorry for so many dumb questions, I’m just afraid of breaking something.
: