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 ? Commented Apr 16, 2019 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
    Commented Apr 16, 2019 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. Commented Apr 16, 2019 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
    Commented Apr 17, 2019 at 7:53

3 Answers 3


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
    Commented Apr 17, 2019 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. Commented Apr 18, 2019 at 17:37
  • I ran all commands as root. Nothing happens.
    – Frederik
    Commented Apr 23, 2019 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
    Commented Aug 14, 2020 at 12:18

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.

  • 1
    How's this any easier than poweroff? Or is that a security issue that we should get rid of too? Commented May 30, 2020 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
    Commented May 31, 2020 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? Commented May 31, 2020 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
    Commented Jun 3, 2020 at 6:48
  • 1
    A normal power-off is a controlled process that allows server processes to be shut down, filesystems unmounted and write caches cleared, all in an orderly fashion without losing data. A kernel panic abruptly stops all user-space processing (equivalent to kill -9 for everything), and may also prevent an orderly shutdown of filesystems, risking filesystem corruption and data loss as cached writes won't get all the way to the disk.
    – telcoM
    Commented Aug 14, 2020 at 12:46

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .