[RFC] Socket activation support for PHP-FPM View as Markdown

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