# [RFC] Socket activation support for PHP-FPM

- Thread: https://externals.io/message/63534
- Original archive: https://news-web.php.net/php.internals/63534
- Started by David Strauss on 2012-10-18T20:41:26+00:00
- Messages: 7
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #63534 — David Strauss — 2012-10-18T20:41:26+00:00

URL: https://externals.io/message/63534#63534

The full RFC, including initial patches, is here:
https://wiki.php.net/rfc/socketactivation

In short, this allows spawning a PHP-FPM pool on-demand with systemd
initializing the main socket.

-- 
David Strauss
   | david@davidstrauss.net

---

## #63535 — Reinis Rozitis — 2012-10-18T21:03:05+00:00

URL: https://externals.io/message/63534#63535 · In reply to: #63534

> In short, this allows spawning a PHP-FPM pool on-demand with systemd 
> initializing the main socket.

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

rr

---

## #63536 — David Strauss — 2012-10-18T21:39:41+00:00

URL: https://externals.io/message/63534#63536 · In reply to: #63535

> 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

---

## #63537 — David Muir — 2012-10-18T23:06:26+00:00

URL: https://externals.io/message/63534#63537 · In reply to: #63534

> The full RFC, including initial patches, is here:
> https://wiki.php.net/rfc/socketactivation
>
> In short, this allows spawning a PHP-FPM pool on-demand with systemd
> initializing the main socket.
>

Upstart support would be good to have too.

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

Cheers,
David

---

## #63538 — David Strauss — 2012-10-18T23:16:48+00:00

URL: https://externals.io/message/63534#63538 · In reply to: #63537

> 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

---

## #63539 — Rasmus Lerdorf — 2012-10-18T23:35:36+00:00

URL: https://externals.io/message/63534#63539 · In reply to: #63538

> 
> > […]
> 
> 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 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.

Note though that in order for pools to share an opcode cache they must
be forked from the same parent process. There are ways to work around
that, but it requires some fancy fd passing footwork in APC and I guess
in many instances you don't actually want to share across pools anyway.

-Rasmus

---

## #63540 — David Strauss — 2012-10-18T23:42:58+00:00

URL: https://externals.io/message/63534#63540 · In reply to: #63539

> Note though that in order for pools to share an opcode cache they must
> be forked from the same parent process. There are ways to work around
> that, but it requires some fancy fd passing footwork in APC and I guess
> in many instances you don't actually want to share across pools anyway.

That's certainly the case. I'll update the RFC.

-- 
David Strauss
   | david@davidstrauss.net