3 ms·

Kernel panics work very well for this use case. echo c > /proc/sysrq-trigger

by 0xEFF 6y ago

raverbashing 6y ago
For reference: https://unix.stackexchange.com/a/66205 https://unix.stackexchange.com/a/66205 (you obviously need to be root)}
derefr 6y ago
Maybe for testing the crash-resilience of software running on the node; but not necessarily for testing how the SDN autoscaling glop you've got configured responds to the node's death. A panicking instance is still "alive" from its hypervisor's perspective (either it'll hang, sleep, or reboot, but it won't usually turn off its vCPU in a way the hypervisor would register as "the instance is now off"); while if a hypervisor box suffers a power cut, the rest of the compute cluster knows that the instances on that node are now very certainly off.
- kl4m 6y ago
  echo o > /proc/sysrq-trigger will shutdown a AWS instance immediately. I've used it a couple of times to make real sure my costly spot instance was terminated. https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html#what-are-the-command-keys https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html...
  - derefr 6y ago
    https://elixir.bootlin.com/linux/latest/source/kernel/power/poweroff.c#L21 https://elixir.bootlin.com/linux/latest/source/kernel/power/... Looks like SysRq-o does a clean poweroff, not a dirty/immediate one — it calls kernel_power_off(), not machine_power_off(). This means, importantly, that can actually take some time to happen, as drivers get a chance to run deinitialization code. This also means that a wedged driver that doesn't respond during deinit can prevent the kernel from halting. Thus, while SysRq-o might be useful for killing a wedged userland, it's not a panacea — especially, it isn't guaranteed to complete a shutdown for unstable kernels, or kernels with badly-written DKMS drivers attached. It's not truly equivalent to a power-cut.

3 ms·

Kernel panics work very well for this use case. echo c > /proc/sysrq-trigger

by 0xEFF 6y ago

Kernel panics work very well for this use case. echo c > /proc/sysrq-trigger

raverbashing 6y ago
For reference: https://unix.stackexchange.com/a/66205 https://unix.stackexchange.com/a/66205 (you obviously need to be root)}
derefr 6y ago
Maybe for testing the crash-resilience of software running on the node; but not necessarily for testing how the SDN autoscaling glop you've got configured responds to the node's death. A panicking instance is still "alive" from its hypervisor's perspective (either it'll hang, sleep, or reboot, but it won't usually turn off its vCPU in a way the hypervisor would register as "the instance is now off"); while if a hypervisor box suffers a power cut, the rest of the compute cluster knows that the instances on that node are now very certainly off.
- kl4m 6y ago
  echo o > /proc/sysrq-trigger will shutdown a AWS instance immediately. I've used it a couple of times to make real sure my costly spot instance was terminated. https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html#what-are-the-command-keys https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html...
  - derefr 6y ago
    https://elixir.bootlin.com/linux/latest/source/kernel/power/poweroff.c#L21 https://elixir.bootlin.com/linux/latest/source/kernel/power/... Looks like SysRq-o does a clean poweroff, not a dirty/immediate one — it calls kernel_power_off(), not machine_power_off(). This means, importantly, that can actually take some time to happen, as drivers get a chance to run deinitialization code. This also means that a wedged driver that doesn't respond during deinit can prevent the kernel from halting. Thus, while SysRq-o might be useful for killing a wedged userland, it's not a panacea — especially, it isn't guaranteed to complete a shutdown for unstable kernels, or kernels with badly-written DKMS drivers attached. It's not truly equivalent to a power-cut.