I'm using Solus 4.0 (in a VM) and trying to make screenshots of "typical" kernel panic output ("BSOD"). The init system in Solus is systemd.

I tried the following commands in the terminal without success:

$ kill -6 1

Doesn't do anything (no echo).

$ sudo kill -SEGV 1

Also does nothing...

# echo c > /proc/sysrq-trigger

Freezes the system but it's not what I need.

Any ideas?

I'd like to see the stack calls and all. It's not about freezing the system with a fork bomb.

References used:

  • A BSOD is Windows; it's a Blue Screen Of Death. In UNIX/Linux, it is called an Oops. Have looked at opensourceforu.com/2011/01/understanding-a-kernel-oops ? – Ljm Dullaart Apr 16 '19 at 16:10
  • Yes, that's why I put quotation marks around it. Do you have any idea how to answer my question, though? – Frederik Apr 16 '19 at 16:26
  • The link I added suggests that you could use a kernel module to generate the oops. Rather than copying someone else's work, I referred to it. – Ljm Dullaart Apr 16 '19 at 16:30
  • Thank you. I had considered writing a little C program but I'd like to do it via the terminal. If all else fails, I'll try your suggestion. – Frederik Apr 17 '19 at 7:53

If you would like to see stack traces of the threads running on all CPUs you can

# echo l > /proc/sysrq-trigger

According to, e.g., Wikipedia this

Shows a stack backtrace for all active CPUs.

  • Thanks, I tried lots of command keys ("c", "l", "p", etc.) but I get bash: /proc/sysrq-trigger: Permission denied The "magic SysRq key" doesn't work either. Maybe I have to head to the Solus Linux forums? – Frederik Apr 17 '19 at 7:55
  • Permission denied probably means that you did not run above commands as root. Try again as root (which I meant to indicate by the "#" prompt) and it should work. However in any case it is possible that the kernel was compiled without support for magic sysrq. But OTOH I think you should not get permission denied but rather /proc/sysrq- trigger should not exist at all. – Erki der Loony Apr 18 '19 at 17:37
  • I ran all commands as root. Nothing happens. – Frederik Apr 23 '19 at 6:58
  • It is possible to selectively disable some of the magic SysRq functionality at kernel compile time, using the CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE configuration parameter, or at runtime, by setting kernel.sysrq to a value that is neither 0 nor 1 in /etc/sysctl.conf, or by just echoing that value to /proc/sys/kernel/sysrq. The kernel admin guide has more info. If the stack-trace command key has been disabled, but other functions remain enabled, that might explain the "permission denied" error. – telcoM Aug 14 '20 at 12:18

A reliable way to cause a kernel panic from userspace is to get PID 1 to exit. It's protected from signals, so you'll have to use a different approach, like a debugger: sudo gdb -ex 'call _exit(0)' --pid=1 --batch


Ideally this should not be possible at all, otherwise hackers would be able to bring systems down too easy. If you've found a way to do that, that may be severe security issue.

  • How's this any easier than poweroff? Or is that a security issue that we should get rid of too? – Joseph Sible-Reinstate Monica May 30 '20 at 20:57
  • To have tools like poweroff/shutdown/reboot work, user must have certain capability, CAP_SYS_BOOT. That means you can configure user so that it doesn't have it and as result he cannot reboot or shutdown server suddenly. – ivan.ukr May 31 '20 at 8:31
  • So why should forcing a panic "not be possible at all" if it's fine for poweroff to be possible for users with CAP_SYS_BOOT? – Joseph Sible-Reinstate Monica May 31 '20 at 15:23
  • Because poweroff is sort of useful and normal action. While "force kernel panic" is sort of thing that may be useful maybe for kernel developers only. So such things should not be normally part of mainstream OS kernel. Instead, developer has to add to kernel something special that would force kernel panic, if that is really what he needs. This could be for example, custom driver for character device, which, if written special symbol sequence, causes kernel panic. – ivan.ukr Jun 3 '20 at 6:48
  • They both have the same net effect of rendering the system unusable until someone manually reboots it. Why is there a security difference between doing so conventionally and unconventionally? – Joseph Sible-Reinstate Monica Jun 3 '20 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.