Add kern.reboot_on_halt sysctl

[trasz]

Summary

This can be set on machines that can't be power cycled remotely,
to prevent halting them by mistake.

[darkfiberiru_gmail.com]

This is a lot more complicated and code is probably to far down in kernel to do without layer violations/stupid. But having an automode that would check if someone was on a physical console(monitor/keyboard or serial) and if halt is run over ssh or similar(mosh) then reboot instead.

I figure not practically but wanted to raise idea incase it's important to someone else or easy to do.

[mhorne]

I guess you were burnt by this problem @trasz? ;)

I think it is somewhat of a strange band-aid to be honest, but I understand the consequences of an accidental halt on a remote machine. My question really is, is there even a valid use-case to halt the machine but not reboot in 2022? Other than the "importance" of maintaining halt's historical behaviour, I would almost think having kern.reboot_on_halt=1 is a better default.

Also, doesn't an accidental poweroff have the same problem?

I don't oppose the patch as-is, but you should document the tunable somewhere, maybe in halt(8).

In D35222#798435, @darkfiberiru_gmail.com wrote:

This is a lot more complicated and code is probably to far down in kernel to do without layer violations/stupid. But having an automode that would check if someone was on a physical console(monitor/keyboard or serial) and if halt is run over ssh or similar(mosh) then reboot instead.

I figure not practically but wanted to raise idea incase it's important to someone else or easy to do.

Agreed with the sentiment entirely, but you are correct about layering here.

[imp]

Halting the machine is still important in 2022. A number of people want to power it off afterwards, though sometimes the automatic power is busted.

[trasz]

I've been burned by this in the past, but I've assumed it's just me. This time, though, there was another person involved, and this made me reconsider. In this case it's not even that it's a remote machine: this is for a homebrew remote management mechanism; essentially we have BeagleBone Blacks hooked up to the actual machines (mechanically they are inside the machines), which provide remote console and virtual media, and halting one of those by mistake - for example when you fail to notice the cu(1) to the "real" machine has been disconnected - results in having to power cycle the whole thing, which is one thing our BBB-based remote management does not provide.

This patch does reboot for both halt(8) and poweroff(8). It doesn't handle entering ddb(4), but there's another sysctl for that one. Thanks for answering my question I forgot to ask, which was what's a good place to document this :-)