WARNING!!!: The question asks for temporarily breaking Ubuntu. There shall be no safe answers. If you have important services running, important documents/files being edited, please note that you might not be able to recover/save your work. Please note that trying these answers is not recommended unless you know what and why you're doing it, and it is not answerer's (or asker's, FWIW) fault if you break something.
I need a way to make my Ubuntu become unresponsive. No running shutdown scripts, no recovery from hanging state. Just a quick and dirty way for the system to go into derp mode. Recovery should be only via powering off and on again.
Assume three things:
- I am root
- Non-bash solution ( so no fork bombs please, but command-line solution ok)
- filesystem must remain intact
To address dobey's comment:
- derp mode basically means "computer runs, but that's it"
- "What you're actually trying to achieve". I think the title explains it pretty clearly. I want to make the OS unresponsive at will, where it won't be able to do anything. That's exactly what I'm trying to achieve. There's no debugging involved, there's no XY problem. I just need a way for system to lock up/crash/hang up where I can't do anything except hold the power down button.
One definite way to make your system unusable is to crash it using:
Or (if your
/proc/sys/kernel/sysrq
setting is set to something not so restrictive, like1
), press Alt + SysRq + C for the same effect.These files are documented in the
proc(5)
manual:For more information about this "sysrq" feature, see https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
Please don't try unless you know exactly what you're doing!
changing
/proc/sys/kernel
settings related to kernel panicThis will set the kernel to panic immediately in case of a hung task(!), an NMI caused by an IO error, an oops or BUG and overflows of kernel, IRQ and exception stacks. While not causing a panic immediately, this should make it much easier to get to the point.
output the system's I/O ports
overwrite the memory device with zeroes
flood system I/O ports with random numbers
using SysRq, perform a system crash by a NULL pointer dereference:
I didn't try any of these. (source 01, source 02, How to cause kernel panic with a single command?, source 04)
Trying:
Followed by:
Should do the trick