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.
Totally switch to a terminal first like you suggested and see if you can work your way from there. My suggestion goes after yours. Always try to fix the running system first.
It’s probably wise to check man pages and other introductory documentation for most system administration tasks. Even though they’re super low-level, they are in my opinion better to send than just pulling the power plug.
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.
Totally switch to a terminal first like you suggested and see if you can work your way from there. My suggestion goes after yours. Always try to fix the running system first.
It’s probably wise to check man pages and other introductory documentation for most system administration tasks. Even though they’re super low-level, they are in my opinion better to send than just pulling the power plug.