supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jeff <sysinit@yandex.com>
To: supervision@List.skarnet.org
Subject: ipc in process #1
Date: Thu, 9 May 2019 09:10:21 +0200	[thread overview]
Message-ID: <20190509071019.GE4017@panda> (raw)


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.



             reply	other threads:[~2019-05-09  7:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09  7:10 Jeff [this message]
2019-05-10 17:57 ` Laurent Bercot
2019-05-11 11:26   ` SysV shutdown util Jeff
2019-05-11 12:56     ` Laurent Bercot
2019-05-11 12:38   ` emergency IPC with SysV message queues Jeff
2019-05-11 13:34     ` Laurent Bercot
2019-05-16 15:15       ` Jeff
2019-05-16 21:25         ` Laurent Bercot
2019-05-16 21:54           ` Oliver Schad
2019-05-19 17:54           ` Jeff
     [not found]             ` <CALZWFRJws+eDthy8MCFj4PiVdRdRpM+afda6QAbEtYA4NT8ESQ@mail.gmail.com>
2019-05-19 19:59               ` Fwd: " Cameron Nemo
2019-05-19 20:26             ` Jeff
2019-05-19 18:38           ` Bob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190509071019.GE4017@panda \
    --to=sysinit@yandex.com \
    --cc=supervision@List.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).