3 ms·
*Groans* ...OK, after having a bit of a poke around I would respectfully ask for a demonstration/citation of this insanity. My own experience is that systems
by exikyut 4y ago
*Groans*
...OK, after having a bit of a poke around I would respectfully ask for a demonstration/citation of this insanity.
My own experience is that systems that panic get rather warm, which I blindly assumed was because the kernel had entered an infinite loop. This turns out to be the case: https://github.com/torvalds/linux/blob/cbe232ab07ab7a1c7743c94c53d0e0d50c3d1b88/kernel/panic.c#L396-L403 https://github.com/torvalds/linux/blob/cbe232ab07ab7a1c7743c...
There are references to interacting with kgdb, booting a crash kernel, and delaying before reboot above the highlighted spot in the previous link. This suggests that panicking is very much a "everything is torn to shreds and never comes back again" event.
Annoyingly I can't SIGKILL, -TERM, or -SEGV `init` easily (PID 1 is special-cased by the kernel), and don't remember exactly how to fire up my kernel initramfs test harness, so I can't properly test this easily at the moment. Am very curious though.
- bentinney 4y agoI was able to crash a systemd version 245 init on an ubuntu machine via gdb a few minutes ago as a test. It did max out the virtual CPUs on the ESXI host. And while it did not cause the machine to reboot, it seems to have taken down all the processes with it, as SSH and NGINX also crashed and froze the console as well...