From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2618 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Cameron Nemo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Fwd: emergency IPC with SysV message queues Date: Sun, 19 May 2019 12:59:43 -0700 Message-ID: References: <20190509071019.GE4017@panda> <7911341557578305@sas1-23a37bc8251c.qloud-c.yandex.net> <856441558019755@sas1-cd55e40a6ba0.qloud-c.yandex.net> <20190519175450.GB4861@panda> 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="130247"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision@list.skarnet.org Original-X-From: supervision-return-2208-gcsg-supervision=m.gmane.org@list.skarnet.org Sun May 19 22:00:00 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 1hSRyR-000Xix-RY for gcsg-supervision@m.gmane.org; Sun, 19 May 2019 21:59:59 +0200 Original-Received: (qmail 20449 invoked by uid 89); 19 May 2019 20:00:25 -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 20442 invoked from network); 19 May 2019 20:00:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Vln1i1ku1ZQYS43o+Juugb/U9rnxUM4dBgwh7gl7Sm4=; b=jZRQvCVV51g0GPc+1/tLioGsjno1F9ucnobnJjjh35KY4DOLpzp6ihd2gY9Zsycbfu w5fumj6SUJhLBz7NzIYoF00sNXODa4qun5vvq7ghEoZm/pemTwU2IPT/i/FBP/qBmbrD kOGNGk+vpHlADKtXgRkxBeM9CSskkVndl0MaKkcKKj8F5gCv+s8e+ooJ11vdNClz/ju0 8/L2V0zrEK+HVB3NMrVZ3WLnRuLpqS4iPkdG9t1XNsGfYi7/a9sqr6oJBq6rjtPgSbCf 5p8Rn+9WkbP4ClhFYF4YftjkR57Z5Wjx+EnfgLnAknW/Izu1h2jnnoOQWgoQh5HnLEO4 bQVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Vln1i1ku1ZQYS43o+Juugb/U9rnxUM4dBgwh7gl7Sm4=; b=eR728macS7rWz5agulJ2Iq4QKndQggc6MUJR2dGoRUfYkEIHaN0Cku1Vj21B4eXqn9 GHt6BCrC0yXBl5Vb7jen9gQLzr7j51EPMi8w7+9mJYxfFmnUk8wLA7qyxPSaOWoHq74u bHj4kDSKVSeksXs+FWKR8JiJ+fEeqSA6fteWw7I+DDDp6RyvBbaAmQYQgtn96h333F9o 0ZSlWZpTNiMX3sLlvAMNUiXJ9YngbbMFpM0jh7Lyd8MjdJzh+j9yqwxfVJwxlegX8ER/ Y5mPRBEXLH0scDuTwDqlEvrekYXW2VQlkk2c9xkqz8C2k4K4Q+H1Cn32Ve/lcP5XvGso rfoA== X-Gm-Message-State: APjAAAUSZ5pZ2V2b1/bfhJS5zNws2VPGx0WtKBRNHPcne46ch91r7W7E U6iolC68Xe9TGchK6Kb68vUl2s4K/KhXab7RXOnXLQ== X-Google-Smtp-Source: APXvYqzHK9hA5zdVL5ZWnfM6xbDVdu2xDP9MBagVeEAam7xhB7wx+Vi1Fr70nruheKsaj8WBA4l82gnLXSIT4XqmPyU= X-Received: by 2002:ac8:2732:: with SMTP id g47mr27582233qtg.156.1558295996684; Sun, 19 May 2019 12:59:56 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2618 Archived-At: On Sun, May 19, 2019 at 10:54 AM Jeff wrote: > [...] > On Thu, May 16, 2019 at 09:25:09PM +0000, Laurent Bercot wrote: > > [...] > > Okay, so your IPC mechanism isn't just message queues, it's a mix > > of two different channels: message queues *plus* signals. > > well, no. the mechanism is SysV msg queues and the protocol for > clients to use to communicate includes - among other things - notifying > the daemon (its PID is well known) by sending a signal to wake it up and > have it processes the request input queue. > you do not use just fifos (the mechanism), there is also a protocol > involved that clients and server use. What details need to be conveyed other than "stand up", "sit down", and "roll over" (boot, sigpwr, sigint)? > > Signals for notification, message queues for data transmission. Yes, > > it can work, but it's more complex than it has to be, using two Unix > > facilities instead of one. > > indeed, this is more complex than - say - just sockets. on the other > hand it does not involve any locking to protect against concurrently > accessing the resource as it would have done with a fifo. > > and again: it is just an emergency backup solution, the preferred way > are (Linux: abstract) unix sockets of course. such complicated ipc is > not even necessary in my case, but for more complex and integrated > inits it is. that was why i suggested in order to make their ipc > independent of rw fs access. Abstract namespace sockets have two shortcomings: * not portable beyond linux * need to use access restrictions * shared across different mount namespaces; one needs a new network namespace for different instances I am considering dropping it for a socket in /run in my supervisor. -- Cameron > > and of course one can tell a reliable init by the way it does ipc. > > > You basically need a small library for the client side. Meh. > > right, the client has to know the protocol. > first try via the socket, then try to reach init via the msg queue. > for little things like shutdown requests signaling suffices. > > > A fifo or a socket works as both a notification mechanism and a > > data transmission mechanism, > > true, but the protocol used by requests has to be desinged as well. > and in the case of fifos: they have to be guarded against concurrent > writing by clients via locking (which requires rw fs access). > > > and it's as simple as it gets. > > the code used for the msg queueing is not complicated either. > > > Yes, they can... but on Linux, they are implemented via a virtual > > filesystem, mqueue. And your goal, in using message queues, was to > > avoid having to mount a read-write filesystem to perform IPC with > > process 1 - so that eliminates them from contention, since mounting > > a mqueue is just as heavy a requirement as mounting a tmpfs. > > indeed, they usually live in /dev/mqueue while posix shared memory > lives in /dev/shm. > > that was reason that i did not mention them in the first place > (i dunno if OpenBSD has them as they usually lag behind the other > unices when it comes to posix conformance). > > i just mentioned them to point out that you can be notified about > events involving the posix SysV ipc successors. > i never used them in any way since they require a tmpfs for this. > > > Also, it is not clear from the documentation, and I haven't > > performed tests, but it's even possible that the Linux implementation > > of SysV message queues requires a mqueue mount just like POSIX ones, > > in which case this whole discussion would be moot anyway. > > which in fact is not the case, try it with "ipcmk -Q", same for the > other SysV ipc mechanisms like shared memory and semaphores. > you can see that easily when running firefox. it uses shared memory > without semaphores akin to "epoch" (btw: if anyone uses "epoch" init > it would be interesting to see what ipcs(1) outputs). > this is in fact a very fast ipc mechanism (the fastest ??), though > a clever protocol must be used to avoid dead locks, concurrent accesses > and such. the msg queues have the advantage that messages are already > separated and sorted in order of arrival. > > > You've lost me there. Why do you want several methods of IPCs in > > your init system? Why don't you pick one and stick to it? > > since SysV msg queues are a quite portable ipc mechanism that does > not need any rw access. so they make up for a reliable ipc backup > emergency method. > > > Sockets are available on every Unix system. > > these days (IoT comes to mind). but i guess SysV init (Linux) does > not use them since there might have been kernels in use without > socket support (?? dunno, just a guess). > on the BSDs this should be true since it was said that they implement > piping via socketpairs. > > > So are FIFOs. > > i do not like to use them at all, especially since they need rw > (is that true everywhere ??). > > > If you're going to use sockets by default, then use sockets, > > and you'll never need to fall back on SysV IPC, because sockets work. > > true for abstract sockets (where available), dunno what access rights > are needed to use unix sockets residing on a fs.