Re: s6, listen(8), etc.

From: Laurent Bercot <>
Date: Tue, 6 Sep 2016 12:18:36 +0200

On 06/09/2016 10:42, Jonathan de Boyne Pollard wrote:
> One dictum is that if you're using the "LISTEN" protocol for any
> UCSPI use-case, you are doing it wrong. The name "LISTEN" in
> "LISTEN_FDS" is a big clue. It's not for accepted socket file
> descriptors. It's for listening ones.
> UCSPI deals in accepted connections, conversely.

  That's right; sorry for entertaining the confusion. I was focusing on the
"pass open fds other than 0, 1 and 2 from the caller to the daemon" aspect,
without considering the nature of the fds.
  I am still of the opinion that the nature of the fds should be a
convention between the caller and the daemon. The most interesting thing
about UCSPI is that it only handles byte streams, so any fd you can
read() from and write() to generally works.

  A socket that hasn't been obtained by accept() is different in that it
has a lot of states (created, bound, listening, and maybe more) in which
you still can't read/write. Each of those states is dynamically testable,
but it's a lot cleaner if the daemon knows what state the fd it receives
is supposed to be in.

> If you think that "here's a bunch of file descriptors" is the
> protocol, then you've missed a subtlety. The protocol is that the
> list of file descriptors is *ordered*, by the system
> administrator/package writer.

  Oh, yes, of course it's ordered. It's a list, not a set - else you
could never make it work without labels. I just find it ugly to test
the type of the received fd dynamically, see below.

> They could equally well define something like "You
> specify my control listening FIFO first, my TCP4 service listening
> socket second, and my TCP6 service listening socket third in the
> list.". How the ordered list of file descriptors is treated is
> defined by the service programs themselves.

  Yes. That was the point I was making: the simplest possible API is a
hardcoded convention from the daemon. LISTEN_FDS just makes it less
flexible, since the control listening FIFO will be 3, the TCP4 listening
socket will be 4 and the TCP6 listening socket will be 5, and the
daemon is not free to use those for another purpose.

  But Daniel's answer, as I understood it, was that some daemons may want
to get *several* fds for the same service: for instance, to listen to a
dynamically specified number of IPv4 addresses in order to provide TCP4
service to all of them. In that case, it is not possible anymore to rely
on fixed fd numbers: and you need to either dynamically test the type
of the fds you receive, or use a "purpose label -> set of fds with that
purpose" map. The latter is a lot more aesthetically pleasing to me than
the former.

Received on Tue Sep 06 2016 - 10:18:36 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC