On Tue 2016-08-30 12:25:37 -0400, Laurent Bercot wrote:
> On 30/08/2016 15:20, Daniel Kahn Gillmor wrote:
>> i assume you mean http://www.skarnet.org/software/s6/ . thanks for the
>> pointer. I'm looking at that, and it looks like s6's preferred form of
>> user contact is via github (i've just submitted a trivial pull request).
>
> Um, not at all. If the homepage gave you that impression, then it's not
> clear enough and I should add a note to it. I only use github as a mirror
> for source browsing and downloading.
Well, your earlier e-mail suggested that you don't like reading patches
on mailing lists, and there were two other pull requests that had
already been closed so i made the (apparently wrong) inference. sorry
for the confusion.
> The preferred form of user contact for s6 is through this list - you're
> in the right place. :) What did you want to send a PR about?
it's a bugfix to the web page for s6-ioconnect:
https://github.com/skarnet/s6/pull/3
> Please don't use the term "socket activation": it is a systemd buzzword
> with vague and confusing semantics. See
> http://skarnet.org/software/s6/socket-activation.html
Thanks, once i make it past the angry words, this page has some
interesting ideas to work from. The timing and privilege separation
aspects are still not clear to me yet, but that'll probably come in
time.
> Daemons that use shared state in RAM generally open their sockets
> themselves.
well, sure. they also generally daemonize themselves, which is (quite
reasonably) discouraged under a runit or s6 style architecture, though.
And ones that listen on "privileged" ports (below 1024), or who need to
open listening sockets in places that they themselves wouldn't be able
to create sockets generally start as root and then drop privileges after
opening sockets. some of them don't always drop privileges very
successfully, either :/
I'm looking for supervisors that help me avoid some of that stuff.
systemd is one; runit is another; so (potentially) is s6.
> In any case, I'll probably update s6-ipcserver-socketbinder so it's
> usable with more types of sockets.
cool, thanks!
> I'm very interested in sharing thoughts about that, but you'll
> probably find that I'm *extremely* reluctant to yield an inch when
> negotiating with ideas and protocols that come from systemd
i'm sorry to hear you're so inflexible about this, but that's your call,
i guess.
> while being open to ideas for improving daemon management under Unix;
> and most of those ideas have been floating around - and sometimes
> implemented in supervision suites - since before systemd was a
> thing. ;)
yep, we're all learning from each other, hopefully.
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. 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. So i'm hoping that it'll find a taker
in one of these more toolkit-style supervisor suites.
thanks for the discussion,
--dkg
Received on Tue Aug 30 2016 - 20:51:28 UTC