On Sun 2016-09-04 09:36:38 -0400, Laurent Bercot wrote:
> No, because the daemon doesn't care about the numbers, it cares about
> the use case. The daemon doesn't want to know what fd 3 is about, it wants
> to know what fd it should perform UDP socket operations on.
> If you want to provide several fds for the same use (i.e. a daemon that
> listen on several UDP sockets with the same functionality), then you should
> give a list of fds. "UDP_FD=3,8" for instance. Or, with LISTEN_FDS_MAP,
> something like "udp=3,8:tcp=5".
right, which is the equivalent of:
LISTEN_FDNAMES=udp::tcp:::udp
> Fortunately, it's easy to move fds around. The shell redirection
> operators are getting so little use these days! And for executable chains,
> execline's "fdmove" can be plugged anywhere. Internally, s6-rc makes
> heavy use of fdmove.
As you say, moving file descriptors around is easy. that's why it's not
such a big deal to hardcode starting at 3 :)
> Maybe it's just aesthetics at this point, but I don't like the idea of
> having to inspect the fds you're given. If I'm using preopened sockets, I
> want to be able to trust the caller to pass me the correct socket types
> (and fail loudly if it doesn't). I don't want the caller to tell me
> "here's a bunch of fds, you sort them out": that's just laziness.
so you're willing to check the socket types explicitly (how else would
you fail loudly if they don't match your explanations?) but unwilling
just treat those sockets appropriately given the directives? This seems
like it encourages unnecessary failure modes.
I don't mind the belt-and-supsenders approach if you want it (require
that all udp sockets are explicitly labeled "udp") but it seems like
wasted effort and more fragile code if you can otherwise just expect
that you know what to do with pre-opened sockets based on the data you
can infer from them directly.
> And there are also multiple daemons written and running today that
> already know how to read an open fd number from an environment
> variable,
Sure, and to work with those daemons you'd support the env vars they
use. For daemons that are already using the LISTEN_FDS/LISTEN_FDNAMES
convention, it would make sense to use that convention instead.
> and that didn't wait for systemd to bring them God's gift to daemon
> design. :P
No one is claiming this is "god's gift", but it's a useful convention,
semantically-equivalent to several variants you've proposed here, which
is starting to see wider adoption. It doesn't in any way depend on the
rest of systemd.
> Following existing practice for interoperation purposes is a dangerous
> positive feedback loop: it's only a good thing when the existing practice
> is already good. And I don't subscribe to the "A bad convention is
> better than no convention at all" point of view: if a convention is bad,
> I make it my job to think of a better one instead. This is what we are
> doing right now, this is why I love design discussions, and I thank you
> for this opportunity.
Sure, but coming up with semantically-equivalent new syntax for an
already-deployed construct is fruitless make-work. It looks to me like
your antipathy to systemd (however well-justified it might be) is
pushing you to reject a useful convention just because of its
provenance. That's your call of course, but i don't want to make that
same tradeoff.
All the best,
--dkg
Received on Sun Sep 04 2016 - 14:25:54 UTC