From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2572 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: ipc in process #1 Date: Thu, 9 May 2019 09:10:21 +0200 Message-ID: <20190509071019.GE4017@panda> Reply-To: sysinit@yandex.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="129893"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.0 (2018-05-17) To: supervision@List.skarnet.org Original-X-From: supervision-return-2162-gcsg-supervision=m.gmane.org@list.skarnet.org Thu May 09 09:10:34 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 1hOdCJ-000XZm-9Z for gcsg-supervision@m.gmane.org; Thu, 09 May 2019 09:10:31 +0200 Original-Received: (qmail 19916 invoked by uid 89); 9 May 2019 07:10:54 -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 19909 invoked from network); 9 May 2019 07:10:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1557385825; bh=cTyULeZ+6RKcfj+z8GRIKW+IjFvHtjawGIesV5FC7Kw=; h=Reply-To:Subject:To:From:Date:Message-ID; b=JxAM551gxnG3gA6OScqGeeup1Wnqjy//Hrzbw5r7ilAY3hpMC14pftwuLBZF7Kv0c gf55/Z/o5leqfNp88qCHZv4l5qKjfycKUMD3O6UlO5RcCjI6epKbT9p7PIykaKqwxP DL7PkQk/zr4bFe+fh6R165rIyZlgzLt2QY1J5h/M= Authentication-Results: mxback1g.mail.yandex.net; dkim=pass header.i=@yandex.com Content-Disposition: inline Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2572 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). 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.