>IMO process #1 should be solely signal driven.
>i guess there is no need for further ipc by other means,
>escpecially for those that require rw fs access to work
>(eg fifos, unix sockets).
The devil is in the details here. Theoretically, yes, you're right.
In practice, only using signals to control pid 1 is rather limiting,
and the choice to do so or not to do so is essentially decided by
other factors such as the existing interfaces you want to follow.
For instance, if you want to implement the stage 3 procedure in
pid 1, and you want to follow the LSB interface for the "shutdown"
binary - all of which is the case for sysvinit - then signals are
not enough: you need to be able to convey more information to pid 1
than a few signals can.
But yes, limiting what pid 1 does is reducing its attack surface,
which is a good idea in general, and it is totally possible to
design a correct pid 1 that is only controlled by signals.
>apart from that process #1 has IMO only the additional duty of
>leaving stage 2 and entering staqe 3 when requested.
And reaping zombies, and supervising at least one process. :)
>for those who still need more than what is provided by signals
>i would recommend using abstract unix domain sockets (Linux only)
>or SysV message queues (the latter works even on OpenBSD) since
>those ipc mechanisms can work properly without rw fs access.
Have you tried working with SysV message queues before recommending
them? Because my recommendation would be the exact opposite. Don't
ever use SysV message queues if you can avoid it. The API is very
clumsy, and does not mix with event loops, so it constrains your
programming model immensely - you're practically forced to use threads.
And that's a can of worms you certainly don't want to open in pid 1.
Abstract sockets are cool - the only issue is that they're not
portable, which would limit your init system to Linux only. If you're
going for a minimal init, it's a shame not to make it portable.
Really, the argument for an ipc mechanism that does not require a
rw fs is a weak one. Every modern Unix can mount a RAM filesystem
nowadays, and it is basically essential to do so if you want early
logs. Having no logs at all until you can mount a rw fs is a big
no-no, and being unable to log what your init system does *at all*,
unless you're willing to store everything in RAM until a rw fs
comes up, is worse. An early tmpfs technically stores things in RAM
too, but is much, *much* cleaner, and doesn't need ad-hoc code or
weird convolutions to make it work.
Just use an early tmpfs and use whatever IPC you want that uses a
rendez-vous point in that tmpfs to communicate with process 1.
But just say no to message queues.
--
Laurent
Received on Fri May 10 2019 - 17:57:09 UTC