[RFC] Socket activation support for PHP-FPM

What would be the advantage on using systemd instead of using FPMs native
'ondemand' process manager?

The ondemand process manager still keeps considerable memory
allocated, and PHP-FPM currently has some idle CPU load (<1% per
service, but it adds up when you manage 500+ pools on a box) when not
processing requests.

The ondemand process manager doesn't solve the dependency issue
mentioned in the RFC (a web server requiring PHP-FPM to be ready) or
allow privileges to be dropped before PHP-FPM gets invoked at all. The
latter is useful for platform providers that let users configure
PHP-FPM for their individual use cases but want to provide assigned
"listening" sockets.

Socket activation also supports replacing the entire binary (as with a
PHP-FPM security update) without interrupting listening on the socket.
PHP-FPM supports reloading to a limited degree, but I don't think it's
possible to fully replace the executable.

There is also work underway to have socket activation on the base
system spawn or start full containers (like LXC) on-demand. Since
PHP-FPM will, itself, be in the container, something else needs to
listen on its behalf.

Finally, it's a platform consistency issue. As more services move to
socket activation in Fedora and Red Hat, socket units will become a
sort of "common currency" for configuring which services listen where.

--
David Strauss
| david@davidstrauss.net

Upstart support would be good to have too.

I'm aware of Upstart having some basic socket activation support, and
I'm happy to provide advice on the PHP-FPM/Linux side for integrating
it in follow-up work. All socket activation basically works the same
way, in the sense of a file descriptor getting handed into the daemon.

I eventually foresee either a standardization of environmental
variables for handing in sockets or a "libsocketactivation" that looks
for the appropriate environmental variables for your superserver or
init daemon.

I take it that this would allow restarting specific pools? That would be
a really nice to have.

I didn't really think about it because we've always run an instance of
PHP-FPM per pool to have such capability, but that's certainly the
case. If template-based services (not discussed in or related to the
RFC) like those in systemd become more widespread, I'd imagine a lot
of applications like nginx, Apache, and PHP-FPM could cede their
internal virtual host/multi-pool models in favor of standardized
provisioning of multiple instances.

--
David Strauss
| david@davidstrauss.net