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. 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 doesn't seem to do what i'm proposing with listen(8), though, and listen doesn't quite fit there. For one thing, the socket activation it provides doesn't seem to provide for any shared state between concurrent connections without using the filesystem. Maybe that's a plus, but i don't know of many daemons built to work that way -- they often have shared state directly in RAM, where it's arguably more straightforward to synchronize complex data structures (i'm sure you could do something clever with mmapped files and/or ipc, but i'd have to think about the locking/synchronization stuff there a lot more).
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 s6 provides s6-ipcserver for daemons that can be implemented as one process per connection, but it also provides s6-ipcserver-socketbinder which performs socket(), bind(), listen() and accept(). There's also s6-tcpserver-socketbinder in the s6-networking package. Compared to your "listen" program, they don't support SOCK_DGRAM sockets, and they always accept(). I should patch them, add options so they're more flexible - I'll probably do it in the near future - but the current behaviour accounts for the majority of use cases. Typically, datagrams don't really need that kind of socket-passing magic, because they're used with unreliable protocols in the first place. Daemons that use shared state in RAM generally open their sockets themselves. It's perfectly acceptable as long as they use a notification protocol to signal when they're ready to accept connections. "Socket activation"-mania is an effect of the systemd propaganda; there is value in being able to pass a socket across processes, but it's not where systemd pretends it is. See the above link. In any case, I'll probably update s6-ipcserver-socketbinder so it's usable with more types of sockets.
Anyway, thanks for the pointers. it looks to me like my proposed listen(8) seems to bridge the gap between the daemontools family and the standard daemons that people will want to deploy (which are being updated for systemd) slightly more closely with runit than with s6, but if you're interested in thinking that kind of gap-bridging through with me, i'm certainly interested.
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, because most of these are driven by politics mixed with technology - and that's a unholy union that I'm adamant on purifying. The fact that "standard daemons" (standard as defined by whom?) are "being updated for systemd" is a symptom of the systemd imperialism which I absolutely reject, 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. ;) -- Laurent
