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.

  • NaibofTabrEnglish
    10•6 days ago

    This depends a lot on the type/source of the freeze. What were you doing at the time? Are you experiencing regular crashes? What is your hardware like? (laptop/desktop, year, make, model)

    Is it just the window manager/desktop environment? Ctrl + Alt + F7 should take you to a different TTY session where you can login and give a reboot command. (actually any F# key should work)

    The sysreq keys should always work if the OS is locked up. How are you using REISUB? Do you know what instruction each letter sends? Are you waiting in between pressing them? If using this “borked your PC”, the most likely reason is that your system was busy writing something to the hard drive that is related to the OS and was interrupted. How was it “borked”? Did your bootloader start? Did your OS try to start?

    One thing you can do if nothing seems to be responding is tap the NumLock key. If the indicator light changes you know 3 things:

    1. The keyboard is working.
    2. The USB driver and OS are actively responding to input devices, even if the display is frozen.
    3. The CPU is alive and not stuck.

    If the light changes then you should be able to tap the power button for a soft reset/graceful shutdown.

    If the light does not change then you should first check your keyboard (is it plugged in? is it wireless? does it need a new battery?) but if that’s not the problem then all you can do is force a shut down, because the system is not responding to input.

    There are a lot of potential problems that can produce a “freeze”, with the most basic being an issue with the mouse/keyboard or the USB port they’re plugged into. I once thought my computer was freezing because I was using a Logitech wireless mouse that was bound to 2 different USB receivers plugged into different computers, and the input would randomly switch from one to the other (seriously check the simple stuff first). You could also have a problem with your RAM, hard drive, GPU, CPU or motherboard which could each produce symptoms like freezing. If you have regular crashes you should be checking your hardware.

    To really answer the question “what can I do?” requires more context, and requires you to do some checking to judge the severity of the crash.

    • @SpikesOtherDog@ani.social
      4•6 days ago

      Mint, for me, was freezing up if something like Gimp was running in the background and it goes to sleep. Waking up, it appeared completely locked.

      My system has 16 GB of memory, so I increased the swap from the default 2 GB page file to 16. It’s been a few weeks, but I haven’t seen a lockup.

      My theory was that it was suffering trying to restore memory from hibernation. The only thing helping me was having a SSD, which would eventually catch up and bring me to a properly running state in a few minutes. If it was a spinning player it would never wake up.

      • @floquant@lemmy.dbzer0.com
        2•5 days ago

        Yes, you need enough swap to fit all your RAM’s content to successfully hibernate/hybrid sleep. In the case of regular suspend to ram this shouldn’t happen though

        • @SpikesOtherDog@ani.social
          2•5 days ago

          I have a feeling my swappiness setting was already aggressively paging, so I already had no space. I also turned my swappiness way down.

    • @floquant@lemmy.dbzer0.com
      3•5 days ago

      The sysreq keys should always work if the OS is locked up.

      This used to be the case, but the default configuration of systemd actually disables them and requires manual activation.

      But yeah, knowing what each does and waiting for sigterm, flush, and umount to complete is crucial to avoid borking your system. From the kernel documentation:

      sync(s) is handy before yanking removable medium or after using a rescue shell that provides no graceful shutdown – it will ensure your data is safely written to the disk. Note that the sync hasn’t taken place until you see the “OK” and “Done” appear on the screen.

      umount(u) can be used to mark filesystems as properly unmounted. From the running system’s point of view, they will be remounted read-only. The remount isn’t complete until you see the “OK” and “Done” message appear on the screen.

      A little correction:

      Ctrl + Alt + F7 should take you to a different TTY session where you can login and give a reboot command. (actually any F# key should work)

      Virtual consoles 1, 7, and sometimes 2 are usually “special” in the sense that they host a graphic session or kernel logs or something else that is not a login prompt, while 8 through 12 are not usually allocated.

      Definitely try pressing Ctrl-Alt-F3 if your session hangs (i.e. mouse cursor is unresponsive) before going nuclear with SysRq. Then you can look at logs and resource utilization to try and figure out what’s going wrong rather than murdering your CPU mid-thought.

      Solid troubleshooting advice though! Num lock/caps lock are the definitive way to tell if your CPU is halted or not - but only reliable over a wired USB or PS/2 connection ;)

    • @KokusnussRitter@discuss.tchncs.deOP
      1•5 days ago

      Since crashes usually happened under heavy workload (I guess CPU/RAM heavy stuff) and I didn’t pay attention to swap space before, I think this was the most likely cause. I increased it and will have to wait and see if it helps. If not, I’ll consult your comment here :)

    • Clay_pidginEnglish
      2•6 days ago

      I just wandered by from /All and I want to commend you for putting this much work into a helpful comment.

  • @OneCardboardBoxEnglish
    9•6 days ago

    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.

      • lime!English
        6•6 days ago

        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.

    • @abcdqfr@lemmy.world
      3•6 days ago

      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 :\

      • lime!English
        3•6 days ago

        have you tried other ttys? there could be something running on 2.

        • @abcdqfr@lemmy.world
          1•5 days ago

          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

          1. 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:
              sudo tail -f /var/log/kern.log
              or
              sudo dmesg -w
            • This will show you kernel logs in real time, which is often critical for diagnosing freezes.

          2. Mirror Logs or Virtual Console Across Displays:

            • If your second display doesn’t switch TTYs independently, use a terminal multiplexer (like tmux or screen) to duplicate the kernel log view.
              • Start tmux in TTY1 and attach to it from TTY2:
                tmux
tail -f /var/log/kern.log
                Then on the second TTY:
                tmux attach

          Improve Debugging Workflow

          1. 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.

          2. 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
            • This provides richer debugging output in logs.

          3. 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.

          4. 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.

          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
          • Log Debugging Information:
            • Add debug prints in your app and log them to a file instead of stdout.
      • @deadcream@sopuli.xyz
        2•6 days ago

        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.

    • @SpikesOtherDog@ani.social
      2•6 days ago

      Some desktop environments will allow Ctrl Alt Backspace to restart the environment. It’s the Linux equivalent of killing Windows Explorer, and sometime just as sketchy.

    • @jabathekek@sopuli.xyz
      2•6 days ago

      One time I accidentally went into tty and had no idea what it was. Had to wait a day or so for someone to reply to my stack post telling me what tty was and how to exit it.

  • @MagicShel@lemmy.zipEnglish
    6•6 days ago

    Not that ever found. Ye Olde Power Button. And it does on rare occasion bork something.

    I highly recommend keeping /home on a separate partition from / so that if worse comes to worst, you can reinstall the system and lose pretty much nothing. Most of the time it’s no problem. But sometimes it is.

  • @Hawk@lemmynsfw.com
    5•6 days ago

    On Mint this might not be an issue because you should have swap. But an Out Of Memory situation on Linux is basically non-recoverable (or, not fun – reboot is quicker).

    Try running earlyoom in a tmux session to see if that prevents future crashes.

  • @inductor@aussie.zoneEnglish
    3•6 days ago

    ctrl+alt+ the function keys generally switches to a console interface.

    I don’t use Mint anymore, but I remember sometimes having some success with switching to a console and back.

  • @FizzyOrange@programming.dev
    -5•5 days ago

    No, there’s no proper equivalent to Ctrl-Alt-Del. It’s a major flaw in the Linux desktop. You just have to hard-reboot.

    Edit: Downvotes, but you won’t get any suggestions that match Ctrl-Alt-Del. Only

    • Ctrl-Alt-Fn - Disabled by default in lots of distros I think, and it doesn’t have high priority so it’s not guaranteed to respond like Ctrl-Alt-Del does.
    • Magic SysRq - Zero UI, so you have to magically remember a load of random keys, and there’s no way to kill the specific offending process.
    • Ctrl-alt-backspace - Brute force, kills X (does it even work on Wayland?).

    Prove me wrong. Ctrl-alt-delete will respond even when the system is overloaded, and it lets me interactively see a list of processes and kill one of them. Can you do that in Linux?

    Linux is never going to solve this problem while they treat the UI as “just another process”.