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
Received on Tue Aug 30 2016 - 16:25:37 UTC