ipc in process #1

From: Jeff <sysinit_at_yandex.com>
Date: Thu, 9 May 2019 09:10:21 +0200

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).

process #1 has to react to (some) incoming signals and thus
signal handling has to be enabled anyway (mainly SIGCHLD,
but also for signals that are sent by the kernel to indicate the
occurence of important events like the 3 finger salute et al).

apart from that process #1 has IMO only the additional duty of
leaving stage 2 and entering staqe 3 when requested. this can also
be done by sending process #1 signals that indicate what to do
(reboot, halt, poweroff, maybe suspend). access control is easy here
since only the super-user may signal process #1.
there are also quite a lot of real-time signals that might also be used
for the purpose of notifying process #1.

hence there is no need for further ipc i guess.
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.

SysV msg queues are especially useful in situations that only require
one way ipc (ie the init process just reacts to commands sent by clients
without sending information (results like successful task completion)
back to them) since they are rather portable and provide cheap and easy
to set up access control. and since it is process #1 that is the first
process to create and use a SysV msg queue the usual problems with
SysV ipc ids do not occur at all as process #1 can just grab ANY possible
ipc id, like say 1, without interfering with other processes' msg queues
and so all clients know which msg queue id to use for writing requests
(they can also send a signal like SIGIO to process #1 to wake it up and
have it process its msg queue, process #1's pid is also well known. ;-).

this can also be used as an emergency protocol when ipc by other means
(such as unix sockets) becomes unavailable.
Received on Thu May 09 2019 - 07:10:21 UTC