[systemd-devel] [PATCH] Experimental socket process pool.

[David Strauss]

On Mon, Oct 21, 2013 at 7:08 AM, Tom Gundersen <teg at jklm.no> wrote:
> This is a cool feature. However, it seems to me that adding it to the core
> makes much more sense, that way the children can be managed properly by
> systemd as real services. What problems do you see with adding this to pid1?

There's no inherent technical barrier, but there are some improvements
to make and hurdles to jump.

systemd unshares namespaces for every direct child spawned. Processes
in a pool should usually share the same network namespace, though,
among other resources. systemd core would need to accommodate arrays
of other currently singular, per-service data, like PID files and
status for each child. Given that each child would run as a "main
process" from the daemon's perspective, we'd need to treat it to the
same oversight.

PID > 1 also comes with its advantages. It's an easier place to prove
this idea out in isolation. We can studying accept() as a way to
load-balance a set of modern (often event-oriented) daemons, a problem
that will be equally interesting in or out of core. Because the socket
still gets handed through with a PID > 1 pool manager, there's no
substantial overhead to the running daemons, making it a reasonable
choice for sustained production use.

I'd certainly still to see this in core, eventually.

David