What do I do, when my PC freezes?
Windows has ctrl+alt+del, does Linux Mint has something comparable? The only thing I know about is REISUB, but that borked my PC, so I am hesitant to use that again.
Are there any remaining alternatives to waiting and/or using the power button?
Edit: Thank you all for your insights and possible fixes. Crashes usually happened when I was running (cpu/ram?) heavy workload. Increasing swap space was not even on my radar, so I did that now. :) Hopefully Mint will run more stable now.
Sometimes the freeze might be in the display manager. Eg xorg or your wayland compositor has crashed.
In that case, you can use keyboard controls to change tty and fall back to a text interface. I think it’s ctrl + alt + Fn$number, where $number will correspond to the tty you want. Most graphical sessions launch on tty2, so you would use crtl + alt + F1 to switch to tty1.
From there you can log in and use terminal commands to launch a new gui session, or to try and debug what went wrong. Generally, I’ve only had freezing issues on Linux when my GPU is dying. There was also a period where my work computer didn’t have enough swap space. It would freeze whenever I tried to compile code during a video call.
My display manager keeps hanging during wallpaper engine development, never does respond to Ctrl+Alt+F2. Only REISUB seems to be able to save me. Never had anything borked or out of place after reboot. Any ideas? That still sound like the display driver crashing? Haven’t done much diagnosing since I’d have to cludge through troubleshooting over SSH on Android at random :\
Tried F1-6, no love. Only thing that does respond is the mouse movement… keyboard only responds to input reisub. I think if I am at keyboard and the screen does not lock, any windows open will respond to mouse hover but not clicks… I need a linux doctor lol. Maybe a second display for outputting kernel logs, that would be fun for dev work. Though I feel like ssh is the defacto way to accomplish that… Anything we can accomplish with one host and two displays, no network?
Prompted GPT
It sounds like you’re encountering a kernel-level or X/Wayland-level freeze while developing. The fact that the keyboard is unresponsive except for REISUB
suggests a deep hang in the graphical session or related system processes.
Here’s a practical way to debug and diagnose this issue with two displays and one host, without needing a network:
Setup for Debugging on Two Displays
-
Enable Persistent Kernel Logs on Second Display:
- Use a TTY session on your second display to monitor kernel logs.
- Connect your second display and switch to it using
Ctrl+Alt+F2
(or F3-F6, depending on availability). - Login and run:
orsudo tail -f /var/log/kern.log
sudo dmesg -w
- This will show you kernel logs in real time, which is often critical for diagnosing freezes.
-
Mirror Logs or Virtual Console Across Displays:
- If your second display doesn’t switch TTYs independently, use a terminal multiplexer (like
tmux
orscreen
) to duplicate the kernel log view.- Start
tmux
in TTY1 and attach to it from TTY2:
Then on the second TTY:tmux tail -f /var/log/kern.log
tmux attach
- Start
- If your second display doesn’t switch TTYs independently, use a terminal multiplexer (like
Improve Debugging Workflow
-
Set Up Magic SysRq for More Control:
- If your system allows
REISUB
, the Magic SysRq key is already enabled. You can use other commands to debug live:- Sync and Kill Tasks:
Alt + SysRq + F
can attempt to kill resource-hogging processes. - Toggle TTY:
Alt + SysRq + R
can re-enable raw keyboard input if the GUI is frozen.
- Sync and Kill Tasks:
- If your system allows
-
Enable Kernel Debugging Outputs:
- Append
debug
to your kernel boot parameters in GRUB:- Edit
/etc/default/grub
:GRUB_CMDLINE_LINUX_DEFAULT="quiet splash debug"
- Update GRUB and reboot:
sudo update-grub
- Edit
- This provides richer debugging output in logs.
- Append
-
Use a Non-GUI Target:
- For safer development, switch to a lower system target to prevent full GUI freezes:
sudo systemctl set-default multi-user.target
- Reboot into a non-GUI mode where you can manually start your app, making it easier to debug without freezing the entire desktop.
- For safer development, switch to a lower system target to prevent full GUI freezes:
-
Forcefully Isolate the Process:
- Run your wallpaper application in a separate X server to isolate it:
xinit /path/to/your/app -- :1
- This starts a new X session on display
:1
while keeping your primary desktop untouched.
- This starts a new X session on display
- Run your wallpaper application in a separate X server to isolate it:
Tips to Prevent GUI Freezes During Development
- Limit CPU or Memory Usage:
- Use
ulimit
to restrict resource usage of your program:ulimit -v 1048576 # Limit to 1GB virtual memory
- Use
- Log Debugging Information:
- Add debug prints in your app and log them to a file instead of stdout.
Could be a GPU driver bug. I get them occasionally with amdgpu. In this case only hard reset works (no it’s not a hardware problem, Windows never freezes like that).
BTW you can get logs of the pervious boot using journalctl -b -1
command. Useful for debugging freezes like this.
There was also a period where my work computer didn’t have enough swap space.
Since I am still quite new to Linux, is swap space referring to swap RAM?
swap space is a dedicated place on your hard drive that the OS throws stuff to when there isn’t enough ram for everything. this is called swapping. since the hard drive is involved, swapping can slow things down a lot. if you get close to filling both ram and swap space, the machine starts shedding load by killing programs.