On 30/08/2016 22:51, Daniel Kahn Gillmor wrote:
https://github.com/skarnet/s6/pull/3
Applied, thanks!
Thanks, once i make it past the angry words, this page has some interesting ideas to work from.
My words have all the right in the world to be angry; being calm is an oppressor's privilege. (Yes, I am serious; neither being angry nor being serious about saying that systemd is an oppressor disqualifies me as a valid technical interlocutor.)
i'm sorry to hear you're so inflexible about this, but that's your call, i guess.
Read below for a wonderful example of why. Please don't take it as a personal attack, which it's not, but as criticism of the design of systemd.
At any rate the LISTEN_FDS convention of how to pass labeled file descriptors via a small number of environment variables requires no systemd code whatsoever, and it's described in a relatively simple document.
All I can find about it is the sd_listen_fds() man page, which says: "Internally, ... otherwise, it parses the number passed in the $LISTEN_FDS environment variable..." In other words, this is internal workings of systemd, this is not an official API. If at some point systemd decides to change how sd_listen_fds() is implemented, all the other software relying on LISTEN_FDS will just have to adapt. Even if that convention never changes, a bigger issue is that this use of an environment variable presupposes an architecture that is similar to systemd. A daemon that uses sd_listen_fds() will connect to some hardcoded path to a Unix domain socket to receive the descriptors over (and if it's not hardcoded, it needs to be given in another environment variable such as NOTIFY_SOCKET), which means the supervision architecture also has to provide a daemon that transmits the fds over that socket, etc. etc. In other words, either the supervision architecture looks very much like systemd, or the protocol is unusable. It's the same issue that sd_notify() exhibits - and I have no doubt that it would be the same with other systemd interfaces. LISTEN_FDS, just as NOTIFY_SOCKET, may seem very simple and innocuous protocols at first sight, but when you look a bit deeper, you find that they are designed to tighten systemd's monopoly: if you have an alternative, it has to exactly copy systemd's workings in order to be able to correctly implement the protocols - and at this point, designing an alternative is simply useless. The author of uselessd banged their head against that issue for a long time, and then gave up. The line needs to be drawn much earlier.
It's a reasonable improvement in flexibility over the convention of one-pipe-per-process, I/O on 6+7 and 0+1, and it's not particularly hard to implement.
It doesn't look hard, but it's treacherous. It's just impossible to implement in a modular Unixish way, just as the rest of systemd is: that's exactly what I call "mixing politics and technology" - using innocent-looking technical protocols to promote systemd's agenda. Now you've got a small glimpse of why I'm angry and inflexible.
So i'm hoping that it'll find a taker in one of these more toolkit-style supervisor suites.
s6 already provides a complete set of fd-holding tools. If you have a s6-fdholderd process running, you can give it descriptors via the s6-fdholder-store command, and get descriptors from it via the s6-fdholder-retrieve command. Those commands are chain-loading, so it's easy to call them sequentially to put your process in the exact state you want it, with all the descriptors you need in the right place, before exec'ing into your daemon. It's how s6-rc works internally. -- Laurent