from the last replies we have the following possibilities regarding
process #1's supervision capabilities:
- no supervision/respawning (maybe also not handling system shutdown
at all, too):
simplifies the process #1 implementation (especially in the latter case),
supervision can be delegated
> By this redefinition, a good init is one that doesn't allow systems to go
> vegetable, either by having something they restart, or totally freaking
> out and burning down the world if the one thing they started ever
> vanishes.
>
> sinit could be made proper by forking a thing and then
> issuing
>> If something kills runsvdir, then runit immediately enters
>> stage 3, and reboots the system. This is an acceptable response
>> to the scanner dying, but is not the same thing as supervising
>> it. If runsvdir's death is accidental, the system goes through
>> an unnecessary reboot.
>
> If
> And of course you'd need a shutdown script that PID1
> can call when it gets signals to reboot or poweroff.
that is also an interesting point.
i personally added this to my init. it ran a sript with the received
signal's name and number as parameters to let the user decide
what to do about it (
thanks for the interesting links.
> https://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/cjxc1hj/?context=3
nice exchange of arguments.
> Do not mistake causes for consequences. Things are not correct
> because s6 does them; s6 does things because they a
