Bug#727708: socket activation in upstart and systemd
I've finished my first evaluation of the socket activation facilities
provided by upstart and systemd. I should note that I'm particularly
interested in this functionality personally: I would use it heavily and
intend to support it in my upstream projects, since it combines much of
the resource minimization of xinetd with the speed of long-running daemons
in a particularly satisfying way.
I should note that I've only looked at network sockets, not UNIX domain or
abstract sockets.
The systemd socket activation support and configuration is extremely
well-thought-out, thoroughly implemented, and well-documented. I was
quite impressed. It's a lot to wrap one's mind around the first time you
start using it, since there are several different types of units involved
and another configuration file, and it takes a bit to get used to managing
the service and socket somewhat separately. But once I'd used it for a
while, I got used to it and quite liked it. It nicely handles all of the
various socket binding scenarios that I've run across in years of
maintaining socket-based network services.
The upstart support... well, I think rudimentary is the kind term for it.
Socket activation in upstart feels like a project that someone started and
never really finished. Unless I'm missing some trove of docs, the
documentation seems almost non-existent (#732756). UDP sockets appear not
to be supported at all, which meant that I couldn't even finish my test
case (which happened to be a UDP service). On top of that, upstart's
implementation appears to have the following major deficiencies compared
to systemd's:
* No IPv6 support. Given Debian's long-standing and mostly-complete goal
of supporting IPv6 across the distribution, this is obviously a major
problem. I'm looking at the source for upstart-socket-bridge.c right
now, since I wasn't sure from the documentation, but:
sock->addrlen = sizeof sock->sin_addr;
sock->sin_addr.sin_family = AF_INET;
sock->sin_addr.sin_addr.s_addr = INADDR_ANY;
seems fairly definitive. No IPv6 support of course means that upstart
hasn't even started addressing the various IPv6 support issues that
daemons have to handle and that systemd already has addressed, such as
IPV6_V6ONLY behavior and IP_FREEBIND support.
* One and only one bind address is supported. This is an inherent
limitation in the upstart socket passing protocol, which can only pass a
single socket. This is a significant problem for a lot of server
configuration scenarios, where daemons need to listen on specific IP
addresses and not on others. All of the network daemons I maintain have
supported configuring multiple bind addresses for some time.
There are also numerous minor features supported by systemd that aren't as
important but that I think speak to the quality and completeness of the
implementation, such as binding a socket to a particular network interface
instead of address, configurable socket buffers, configuration for various
TCP and IP options, and support for xinetd-style service activation that
spawns a new process for each incoming connection.
I believe upstart's socket activation code would need significant work
before it could be realistically used in any useful way for network
services in Debian. systemd's support looks ready for widespread
production use right now. I intend to configure my package in the next
upload to use socket activation with systemd if available.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: