"Zack Weinberg" <[email protected]> writes: > It's not great having something as large and complicated as the Guile > interpreter running as PID #1. There's actually a couple of bugs that > got wontfix'ed because the issue boils down to "the interpreter's self- > initialization process assumes more of the normal runtime environment is > available than what the first user space process gets and there's > nothing we can do about it" (https://codeberg.org/guix/guix/issues/735 > and https://codeberg.org/shepherd/shepherd/issues/53 ). But leaving > those aside -- they are largely cosmetic -- it's *dangerous* to put a > lot of code in process 1, because more code means more bugs, and if > process 1 crashes it takes out the entire system.
Well, if the real Shepherd dies, the system will probably not be able to recover regardless whether it was PID 1 or PID 2. Even if you would have shell open at the moment, `shutdown' will not work (it talks to shepherd). Though I obviously did not test this, and maybe the system would remain usable. No idea. > > So I had an idea: what if we had a couple of tiny programs *not* written > in Guile, one of which would do *just* what the kernel needs process 1 > to keep doing forever (i.e. call wait() in an endless loop), and the > other one to get the first tiny program plus the real Shepherd started? > And here they are: > > https://git.sr.ht/~zackw/rc-shim > > These are proof-of-concept implementations right now; notably, I do not > know whether it is *useful* for "nanoreaper" to forward orphaned process > exit notifications to the real Shepherd, and nothing has been tested in > "real life" usage. But they should be robust enough to experiment with, > at least. I'd like to hear whatever you have to say about them. Obvious question I guess is why not just use `tini'? It works well, is packaged in Guix and battle-tested. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
