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).
Received on Fri May 03 2019 - 00:53:21 UTC