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