Re: s6, listen(8), etc.

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com>
Date: Tue, 6 Sep 2016 09:42:43 +0100

Laurent Bercot:

> fds 6 and 7 are only used for UCSPI clients, which are a very minor
> subset of the programs you'd want to use that mechanism with.
>
Laurent Bercot:

> I don't want the caller to tell me "here's a bunch of fds, you sort
> them out": that's just laziness.
>
Just so that everyone is not operating under any more misapprehensions:

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. The systemd people
reinvented their own, pretty poor, protocol for accepted connections.
It is not the "LISTEN" protocol. In 2015 I tried to point them at UCSPI
where there's years to decades of existing practice, doco, and
implementation (including GNU inetd!) to gain from. See
https://lists.freedesktop.org/archives/systemd-devel/2015-June/033299.html

(The UCSPI FGA is now http://jdebp.eu./FGA/UCSPI.html , by the way.)

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.
The systemd manual pages explain that it's the order that the various
ListenXXX directives occur in the .INI file. (systemd treats .INI files
as ordered in various ways, of which this is one.) In the nosh toolset,
it's simply the order in which you chain together the chain-loading
*-listen tools. Each tool appends a further listening file descriptor
to the end of the list that it begins execution with.

So whilst in the wild generally programs just scan the whole list
looking for the first/last file descriptor whose type (FIFO, socket
address family, and so on) they like, on the basis that they are
generally only looking for one file descriptor of any type, this is an
interpretation that's defined by the particular server programs
concerned. 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.
Received on Tue Sep 06 2016 - 08:42:43 UTC

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