From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2578 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: ipc in process #1 Date: Fri, 10 May 2019 17:57:09 +0000 Message-ID: References: <20190509071019.GE4017@panda> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="104794"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.34711.0 To: supervision@list.skarnet.org Original-X-From: supervision-return-2168-gcsg-supervision=m.gmane.org@list.skarnet.org Fri May 10 19:56:29 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hP9kz-000R7H-8A for gcsg-supervision@m.gmane.org; Fri, 10 May 2019 19:56:29 +0200 Original-Received: (qmail 15346 invoked by uid 89); 10 May 2019 17:56:52 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 15339 invoked from network); 10 May 2019 17:56:52 -0000 In-Reply-To: <20190509071019.GE4017@panda> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2578 Archived-At: >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