[systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons

[David Strauss]

On Wed, Oct 16, 2013 at 6:59 AM, Kay Sievers <kay at vrfy.org> wrote:
> Also this thing does not actually *activate* anything it just proxies.

I was going more for socket *activated* proxy, in the sense that the
proxy uses socket activation to get its listen() fd.

> And long-running processes should get a d(aemon) at the end.

Agreed here. Not sure why I forgot about that. I'll add that in.

> So why not just call it systemd-socket-proxyd.

It doesn't emphasize the main reason someone would use this over
existing tools. (Admittedly, "sa" doesn't do so too directly, either.)
Say the word "proxy" to someone who's a developer or in IT, and
they'll already assume it's a proxy based on *sockets*, even if they
don't know what sockets are, exactly. We can compare to these
established ones:

 * haproxy can do pure TCP (protocol neutrality) at scale
(event-driven), but it can't start with socket activation or use Unix
sockets.
 * socat is also protocol-neutral, but it assumes any inherited socket
is post-accept(). It can only do listen() if it doesn't inherit the
socket. There are also questions about its performance and reliability
at scale (it's thread-based). It's not really designed to be a
long-running daemon.
 * nginx can inherit sockets and run at scale (event-driven), but it's
protocol-constrained to HTTP and SMTP, maybe one more.

The proxy here (1) accepts an inherited socket for activation, (2)
works with Unix domain sockets, (3) is protocol-neutral, and (4)
should work at scale. Of those four characteristics, I consider the
first (socket activation) the most novel and the main reason someone
would opt for this proxy over other, established ones.

This systemd-bundled proxy should work for creating
socket-activate-able MySQL, Redis, Tomcat, Cassandra, some of which
may never get native socket activation support.

Would systemd-activated-proxyd work? I'd also consider
systemd-socket-activated-proxyd.