There are a couple of things you can do.
If it is frozen then try pressing ctrl+alt+1/2/3/4 to swith to a different terminal this will let you either restart your DE or reboot the system safely.
As far as debugging it I would typically start with looking at journal logs journalctl -b-1 should show you logs from the last boot.
Even with a frozen system you can often still ensure data is written to inspect on the next boot. You may have a key labeled SysRq which likely needs an Alt modifier to trigger.
Alt+Shift+SysRq+s to sync data to disk. Alt+Shift+SysRq+u to unmount the disks.
Alt+Shift+SysRq+b to reboot the system.
Execute them in that order.
This can help ensure the data about the mishap is written to disk so it can be inspected after the forced reboot. I also check the logs in /var/log but I suppose all of those are in journalctl too these days.
You just reminded me … Before I really got into IT in my career I was at a job that still had a messenger for the internal staff. I set my status message in it to “Raising Skinny Elephants Is Utterly Boring.”
I got chastised and made to change it, because the message might offend … Skinny elephants, I guess? I never got clarification on that.
Seems weird that you’d sync before terminating and killing processes. I prefer “Raising Elephants Is So Utterly Boring”. Although some distros only enable the S, U, B/O anyway.
I’m not sure that I would recommend a newer user use sysrq. It is a very powerful tool that you definitely should not be blindly following from a random internet post without knowing what each command does.
In a truly frozen system then it can be good, but only as a final last resort. If the system can be unfrozen by other methods then that should be preferred instead.
There are a couple of things you can do. If it is frozen then try pressing ctrl+alt+1/2/3/4 to swith to a different terminal this will let you either restart your DE or reboot the system safely.
As far as debugging it I would typically start with looking at journal logs
journalctl -b-1should show you logs from the last boot.Even with a frozen system you can often still ensure data is written to inspect on the next boot. You may have a key labeled SysRq which likely needs an Alt modifier to trigger.
Alt+Shift+SysRq+s to sync data to disk. Alt+Shift+SysRq+u to unmount the disks. Alt+Shift+SysRq+b to reboot the system.
Execute them in that order.
This can help ensure the data about the mishap is written to disk so it can be inspected after the forced reboot. I also check the logs in /var/log but I suppose all of those are in journalctl too these days.
You just reminded me … Before I really got into IT in my career I was at a job that still had a messenger for the internal staff. I set my status message in it to “Raising Skinny Elephants Is Utterly Boring.”
I got chastised and made to change it, because the message might offend … Skinny elephants, I guess? I never got clarification on that.
(The manager had no clue what it meant.)
Seems weird that you’d sync before terminating and killing processes. I prefer “Raising Elephants Is So Utterly Boring”. Although some distros only enable the S, U, B/O anyway.
Couldn’t say - I’ve never had the chance to use it. In fact, I’m not sure I ever had the SysRq key on a keyboard I’ve used.
I have had a Pause/Break key and used to think they were the same thing, but now I’m not so sure.
Its the same as the Print Screen key.
I’m not sure that I would recommend a newer user use sysrq. It is a very powerful tool that you definitely should not be blindly following from a random internet post without knowing what each command does.
In a truly frozen system then it can be good, but only as a final last resort. If the system can be unfrozen by other methods then that should be preferred instead.