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 are correct. well i thought it inherited that behaviour from daemontool's svscan. no i understand that this was a totally wrong assumption. :PP > Then you are free to use one of the many incorrect inits out there, > including sinit, Rich Felker's init, dumb-init, and others. You are > definitely not alone with your opinion. i wrote such an init myself which did a bit more than the ones you mention. it ran REALLY fast. the only thing that was slow was my usage of a customized (older) version of OpenRC (since i have written some own openrc scripts (adding perp "support" et al) and am too lazy to write my own scripts currently). > However, you sound interested in process supervision indeed. it's just a question of where to put the supervisor. > if you subscribe to that idea, then you > will understand why init must supervise at least 1 process. ok, i understand your arguments and of course there is something true about it. > Maybe you've never bricked a device because init didn't respawn > anything. well, i bricked my desktop when doing init experiments. but almost immediatly after hosing the system it comes into my mind what exactly went wrong and i fix this on reboot. i was forced to reboot from a rescue dvd only once so far. ;-) (when testing "ninit" which i don't recommend) and it involved only mounting the root fs on disc rw and fixing some symlinks in /sbin (init et al), so this was no real problem so long as one has console access. that's why i wrote (/sbin/)testinit that forks, execs into the real init to test in process #1 and sleeps a while in the child process after which it kill()s process #1 with given signals. this works usually very well and is safe to do. > I have. The "rather artificial and constructed argument" > happened to me in real life, and it was a significant inconvenience. oh no, i hope it was not a remote server ... :-/ always try things out on a box you have console access to or in a vm. BTW: what init systems do this list's subscribers use ? i use statically linked (musl) BusyBox init (and gettys) + mksh (https://www.mirbsd.org/mksh.htm) + s6 + OpenRC (v0.34.11, outdated) as default init system. i also ran perp but now run everything to be supervised under s6, started via a little setup shell script directly from /etc/inittab (most "one time tasks" are indeed directly run from the inittab file instead of a shell script).
