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