From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2603 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: emergency IPC with SysV message queues Date: Thu, 16 May 2019 21:25:09 +0000 Message-ID: References: <20190509071019.GE4017@panda> <7911341557578305@sas1-23a37bc8251c.qloud-c.yandex.net> <856441558019755@sas1-cd55e40a6ba0.qloud-c.yandex.net> 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="14496"; 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-2193-gcsg-supervision=m.gmane.org@list.skarnet.org Thu May 16 23:24:26 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 1hRNrW-0003dI-6a for gcsg-supervision@m.gmane.org; Thu, 16 May 2019 23:24:26 +0200 Original-Received: (qmail 9345 invoked by uid 89); 16 May 2019 21:24:51 -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 9338 invoked from network); 16 May 2019 21:24:51 -0000 In-Reply-To: <856441558019755@sas1-cd55e40a6ba0.qloud-c.yandex.net> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2603 Archived-At: >> Please stop breaking threads. This makes conversations needlessly >> difficult to follow, and clutters up mailboxes. >i do that intentionally since i find the opposite easier to follow. >that leads often to complaints on other lists aswell. Oh? And the other complaints haven't given you a clue? We are a friendly community, and that includes choosing to follow widely adopted threading conventions in order to make your readers comfortable, instead of breaking them because you happen not to like them. Please behave accordingly and don't be a jerk. >> Operations such as msgsnd() and msgrcv() are synchronous and >> cannot be mixed with asynchronous event loops. >what does that exactly mean ? do you mean they block ? >this not the case when the IPC_NOWAIT flag is used. No, it means you cannot be notified of readability or writability, they do not work with poll(). Sure, you have a flag that makes them non-blocking, but to use it, you need to either loop around it, which is polling (i.e. terrible), or to use another channel for notifications. Which is what you are suggesting below: >the client should signal us (SIGIO for example) to wake us up, then >we look at the input queue without blocking (handling SIGIO via selfpipe) >else we ignore the msg queue. Okay, so your IPC mechanism isn't just message queues, it's a mix of two different channels: message queues *plus* signals. 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. You basically need a small library for the client side. Meh. A fifo or a socket works as both a notification mechanism and a data transmission mechanism, and it's as simple as it gets. >and i have not even mentioned posix message queues which can be >used from a select/poll based event loop ... 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. 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. >* SysV ipc is just used as a backup ipc protocol where unix (abstract > on Linux) sockets are the preferred default method > (and signals of course). 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? Sockets are available on every Unix system. So are FIFOs. 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. >just a claim, it is not too much work, now that you beg for it i consider >adding it again, just for you as i would else have restricted myself to >signal handling only which is absolutely sufficient in that case. I have no idea what you are talking about. > ^^^^^^^^^^ see ? how modern ? not that portable, rig= ht ? > there was a reason why the initctl fifo was stored i= n /dev ... Uh, yes, I'm writing an init system for 2019, not for 1992. And *even* in 1992, there was a writable filesystem: /dev. Now I'm not saying that creating fifos in /dev is good design, but I am saying that if you need a writable place to create a fifo, you always have one. Especially nowadays with /dev being a tmpfs, so even if you're reluctant to mount an additional tmpfs at boot time, you can always do stuff in /dev! Needing a writable filesystem to create a fifo or a socket has never been a serious limitation, and nowadays it is even less of a limitation than before. The "must not use the filesystem at all" constraint is artificial and puts a much greater burden on your design than needing a rw fs does. >no this is not portable but your assumption since s6 will not work >without rw which is indeed very limiting and far from correct behaviour. It's really not limiting, and the *only* correct behaviour. The need to have a rw fs does not even come from the daemontools-like architecture with a writable scandir. It comes from the need to store init's logs. Storing logs from an init system is not easy to do. Some systems, including sysvinit, choose to not even attempt it, and keep writing to either /dev/console (which is very transient and not accessible remotely) or /dev/null. Some systems do unholy things with temporary logging daemons. Daemontools (which needs a place to write logs even though it doesn't naturally run as pid 1, and doesn't assume that svscan's stderr points to something sensible) does something that is better than /dev/null or /dev/console, but not by much: it uses readproctitle, which reserves space in its friggin' _argv_ to write rotated logs. And some, including systemd of all things, do the right thing, and actually realize that init's logs are *logs* and should be treated as *logs*, i.e. stored and processed by a *logger program* in the filesystem. And if there's no suitable filesystem at that time, well they create one. Making a tmpfs is *easy*. And it's the only way to get a unified log architecture. >we use normal unix sockets on BSD Oh, so it's not a problem to need a writable filesystem on BSD then? So, why all the contortions to avoid it on other systems? If you're fine with Unix domain sockets, then you're fine with Unix domain sockets and that's it. And there's nothing wrong with that. And you don't need a "portable backup/emergency method" - that just bloats your init system for zero benefit. Z-e-r-o. Zero. >why using semaphores ? they are primarily meant to ease the usage >of SysV shared memory. but epoch init uses shared memory without them. It is true that I didn't back my claim on this page that SysV IPCs have terrible interfaces. At the time of writing, I had tried to use them for an unrelated project and found them unusable; and in 10 years of auditing C code with heavy focus on IPC, I had been submitted *no* code using them, so I thought my opinion was pretty common. That was 7ish years ago. Since then, I have had to work with *one* project using SysV message queues, and my initial impressions were confirmed. I managed to make it work, but it was really convoluted, and a lot more complex than it needed to be; it's *definitely* not an IPC I would choose for a notification mechanism for a supervision suite. I don't know, something about only being usable for data transmission and needing another IPC mechanism to the side for notification makes me think it wouldn't be a good mechanism to use for notification. I just have weird opinions like that. -- Laurent