1

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:

Improve this question
4
  • 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, 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
    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.
    – Ljm Dullaart
    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
    Apr 17, 2019 at 7:53

3 Answers 3

Reset to default
0

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.

Improve this answer
4
  • 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, 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.
    – Erki der Loony
    Apr 18, 2019 at 17:37
  • I ran all commands as root. Nothing happens.
    – Frederik
    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
    Aug 14, 2020 at 12:18
0

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

Improve this answer
-1

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.

Improve this answer
11
  • 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, 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
    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?
    – Joseph Sible-Reinstate Monica
    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
    Jun 3, 2020 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, 2020 at 13:26

You must log in to answer this question.

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