Ive just installed Linux (Fedora 40 KDE) on my main PC over the weekend, so im a complete newbie and i apologize if some of my questions are nonsensical 😅. Yesterday evening the system seemed to completely lock up at a certain point while playing Red Dead Redemption 2 for the first time (installed & run via steam using proton experimental). Id love to know if i handled this situation correctly and how to avoid this or handle it more gracefully in the future. Ill begin by recounting what happened and then ask my questions:
The game froze during a cutscene and continued to play audio for a bit after it froze visually but then that stopped too. I have two monitors, the second completely black screened and the first one was frozen on the last frame of the game. As far as i could tell nothing in KDE was still responding to normal key presses or the mouse.
After a some searching online i decided to try through the ctrl + alt + (f2, f3, … , f6) key combinations to get into a console, that didnt work. As a last resort i tried alt + sysreq (print screen) + REISUB to safely reboot it. That ALSO didnt work, it was p. damn late in the day so i just decided to risk it and use the power button on my pc.
I was prepared for it not to boot anymore due to data corruption or sth, but it seemed mostly fine? My KDE panels were slightly messed up (but that took like 10 sec to fix) and besides that the only odd thing i’ve found so far is that steam refused to start properly and i had to reinstall it.
So did i handle this situation correctly? Specifically:
-
did alt + printscreen + REISUB save my system or do nothing? As i said it didn’t reboot when i did it so i thought it was useless. But after i forcibly restarted my pc and looked it up some more it seems all but alt + printscreen + S may have been disabled, so was alt + printscreen + S responsible for my system still starting without too many problems after i forcibly shut it down?
-
why did this happen & how to prevent it? My system should b powerful enough to run RDR2 (Radeon RX 6800, Ryzen 5 5600X, 32GB ram) and i had nearly no problems up until the crash. So whats at fault? On protondb RDR2 has p. good ratings, did i just get unlucky and found one of the few edge cases where it breaks? But even then, why would a proton/game crash take seemingly the whole OS with it?
-
is it a bad or a good idea to try and trigger this again on purpose? Id really like to know if this was a freak accident or a consistent problem (and if its consistent if eg. switching to proton 9.0.1 alleviates it). So was i lucky that nothing on my PC got badly damaged from this incident and i shouldn’t try to trigger it again for fear of permanent damage? Or can i expect that having to reinstall Steam everytime it crashes is the worst that could happen while testing this?
UPDATE: I went back and did the same part of the game again but this time running it with proton 9.0.1 and the crash still occurred and in the exact same spot in the cut scene too. For reference, it crashed both times during this cutscene: https://www.youtube.com/watch?v=7UHv0SiVhWY @ around 1:23 when the explosion goes off (i only get to hear it briefly the visuals freeze seemingly just before it explodes).
Trying ctrl + alt + f keys didn’t seem to do anything again. I had at least enabled the sysreq keys and REISUB appeared to work and got me back into the system this time without having to adjust KDE panels or reinstalling Steam. Visually the crash was a little different this time, i hit win/meta soon after it happened which after a second or two exchanged the stuck game visuals for a half cutoff browser window on my main monitor (and black otherwise) and my secondary monitor was filled with black and white noise with a bit of color in between.
UPDATE 2 (17/06/2024): I tried it again for the first time since the original post, im now on Kernel 6.9.4 and the crash occured in the exact same spot and looking more or less as described in the previous instances. I managed to get back into a normal state due to alt + sysreq + i (alt + sysreq + k didnt seem to have had any effect).
This is not very common knowledge, but it is no longer recommended to press S or U before B for SysRq. The official documentation of sysrq has stopped recommending this practice, as it may be harmful to modern filesystems. Writing to a storage device while the kernel is in a bad state has the potential to cause corruption, and modern journaling filesystems like EXT4 and BTRFS are designed to survive crashes like this with minimal (or no) corruption. Instead, you’ll likely want to use Alt+SysRq+REIB (and make sure you are waiting multiple seconds between each keypress, as they do not complete instantly!).
You may instead try to kill the most memory intensive non-vital process with Alt+SysRq+RF, which may stop you from crashing to begin with (this works especially well for memory leaks). SysRq+F will invoke the oom (out of memory) killer, which will kill the most memory intensive non-vital process without causing a kernel panic.
If you need to restart, the most ideal situation is to enter a TTY and cleanly reboot, in which case you can do Alt+SysRq+R to grab control from the display manager, then Ctl+Alt+F3 or Ctl+Alt+F4 (I believe most distros have the first login session run on the TTY accessible from Ctl+Alt+F2) to switch to another TTY. You can then log in and do
sudo systemctl rebootif your computer is still responsive. You may need to kill some processes before your system becomes responsive enough to log in on a TTY, which is where Alt+SysRq+F is useful, but in extreme situations it may require Alt+SysRq+EIB.So a basic order of steps to try may look like:
sudo systemctl reboot. Else move onto 3.In the spirit of other users giving mnemonic devices, you could remember REIB with Reboot Even If Broken, or the oom killer RF with Resolve Freeze (someone else can probably think of something better for RF; I’m not great at making mnemonic devices).
TL;DR: There are SysRq combinations that are less prone to damage/corruption than Alt+SysRq+REISUB, so use the above flowchart, or just remove the S and U for Alt+SysRq+REIB (if you don’t want to troubleshoot first) for less chance of filesystem corruption from a bad kernel. You can often recover the system without having to hard reset (Alt+SysRq+B). And ALWAYS wait between SysRq keys, as they do not finish instantly.
This might be just me, but I prefer remembering what the keys actually do:
Also good to know:
Thanks for the detailed explanation on the sysreq keys & when & how to use them for unlocking a frozen system :D. Also for the
systemctlbit because i wasnt even sure what to do if i had gotten to a console lol.There’s also the option of ssh-ing in to remove the offending process, and possibly restart the display manager.
You’ll need to hav another device available of course.