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
Received on Tue Aug 30 2016 - 21:46:24 UTC