Bug#727708: systemd socket activation protocol rationale

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

I've just been reading sd_listen_fds(3).  It's vaguely similar to
upstart's socket activation protocol.  It supports multiple sockets
(which is obviously important).

But I have a few questions about the details:

Why do only some of the environment variables start "SD_" ?
We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

What is the rationale behind the use of the LISTEN_PID variable and
the pid check ?  It seems to me that at the very least this might make
it hard to wrap up a socket-activated daemon in a shell script.

I think it would be good, regardless of what the TC decides on the
init system question for Debian, for systemd and upstart to converge
on a single reasonable protocol.

I observe that upstart's UPSTART_FDS, if extended to multiple sockets,
would require the daemon to do whitespace-separated parsing to extract
the (perhaps noncontiguous) fds.  Whereas systemd's two separate
variables and use of a contiguous fd range is slightly easier to deal
with.

AFAICT it might be possible for both daemons to implement both
protocols.  upstart would have to arrange to make sure that if there
were multiple fds they were consecutive.

Observations and/or opinions from either upstart or systemd welcome.

Ian.