rfc:socketactivation
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:socketactivation [2012/10/18 03:00] – [/etc/systemd/system/my-php-fpm-pool.service] davidstrauss | rfc:socketactivation [2014/04/08 22:52] – Inactive levim | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Version: 1.0 | * Version: 1.0 | ||
* Date: 2012-10-17 | * Date: 2012-10-17 | ||
- | * Author: David Strauss < | + | * Author: David Strauss < |
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
+ | * Patches: [[rfc/ | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Linux distributions with systemd support a " | + | Linux distributions with systemd support a " |
+ | |||
+ | ===== Benefits ===== | ||
+ | |||
+ | Supporting this in PHP-FPM | ||
launchd and legacy internet superservers support socket activation in similar ways. | launchd and legacy internet superservers support socket activation in similar ways. | ||
Line 15: | Line 19: | ||
Socket activation creates no overhead once the daemon has started. systemd does not proxy any traffic; it just hands over the file descriptor. Once the daemon is running and using the systemd-provided socket(s), there' | Socket activation creates no overhead once the daemon has started. systemd does not proxy any traffic; it just hands over the file descriptor. Once the daemon is running and using the systemd-provided socket(s), there' | ||
+ | Socket activation allows 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 it doesn' | ||
+ | |||
+ | There is 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, Arch, Suse, and Red Hat Enterprise Linux (and its derivatives), | ||
===== Implementation details ===== | ===== Implementation details ===== | ||
When systemd starts a socket-activated service, it passes the bound, listening socket in as a file descriptor. PHP-FPM is already accustomed to such behavior using the FPM_SOCKETS environmental variable. It's actually possible to " | When systemd starts a socket-activated service, it passes the bound, listening socket in as a file descriptor. PHP-FPM is already accustomed to such behavior using the FPM_SOCKETS environmental variable. It's actually possible to " | ||
- | It's possible to provide reliable socket activation support by having a loop before or after the " | + | It's possible to provide reliable socket activation support by having a loop before or after the " |
- | Adding the support also requires marking the systemd-imported sockets as persistent past shutdown so PHP-FPM does not close them. | + | Adding the support also requires marking the systemd-imported sockets as persistent past shutdown so PHP-FPM does not perform various cleanup actions on them that break subsequent activations of the service. |
If systemd socket activation support isn't enabled at build time, this feature will have no effect. Even if this feature is enabled for a build, it will have no effect on non-users of socket activation. | If systemd socket activation support isn't enabled at build time, this feature will have no effect. Even if this feature is enabled for a build, it will have no effect on non-users of socket activation. | ||
Line 29: | Line 38: | ||
The recommended use for PHP-FPM with socket activation is a 1:1:1 relationship between the listening socket unit in systemd, the service unit in systemd, and the PHP-FPM pool. This approach allows each pool to spawn on-demand. It also has nice effects like allowing cgroups resource limitations (like CPU shares, memory, block I/O, and network I/O) and security isolations (like PrivateTmp and syscall restrictions) to be set per-pool in the corresponding systemd service unit. Logs will also aggregate per-pool in the systemd journal for the corresponding service. | The recommended use for PHP-FPM with socket activation is a 1:1:1 relationship between the listening socket unit in systemd, the service unit in systemd, and the PHP-FPM pool. This approach allows each pool to spawn on-demand. It also has nice effects like allowing cgroups resource limitations (like CPU shares, memory, block I/O, and network I/O) and security isolations (like PrivateTmp and syscall restrictions) to be set per-pool in the corresponding systemd service unit. Logs will also aggregate per-pool in the systemd journal for the corresponding service. | ||
- | Here's an example configuration. It's still possible to have PHP-FPM drop its own permissions or have it perform its own daemonization fork, but it's unnecessary. | + | Here's an example configuration. It's still possible to have PHP-FPM drop its own permissions or have it perform its own daemonization fork, but it's unnecessary. It's also possible to directly start the PHP-FPM pool without waiting for the first incoming connection; systemd will still start the necessary socket and pass it in. |
====/ | ====/ | ||
Line 52: | Line 61: | ||
==== / | ==== / | ||
+ | |||
+ | It's possible the final implementation may move to " | ||
< | < | ||
Line 68: | Line 79: | ||
</ | </ | ||
+ | ==== Enabling the pool ==== | ||
+ | |||
+ | < | ||
+ | systemctl enable my-php-fpm-pool.socket # Enables the socket at system startup. | ||
+ | systemctl start my-php-fpm-pool.socket | ||
+ | </ | ||
+ | |||
+ | ===== Potential Objections ===== | ||
+ | |||
+ | ==== Why not just use the ondemand process manager? ==== | ||
+ | |||
+ | The ondemand process manager still keeps considerable memory allocated, and PHP-FPM currently has some idle CPU load when not processing requests. It's <1% of a core per service, but it adds up when you manage 500+ pools, each as a service for security/ | ||
+ | |||
+ | The ondemand process manager doesn' | ||
+ | ==== What about Upstart support? ==== | ||
+ | |||
+ | Upstart seems to have basic socket activation support, and integrating PHP-FPM with it would be a great follow-on project. All socket activation basically works the same way, in the sense of a file descriptor getting handed into the daemon. This RFC would pave the way for integration into additional superserver and init daemons. | ||
+ | |||
+ | ==== What about APC opcode cache efficiency? ==== | ||
+ | |||
+ | 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. (Abbreviated from Rasmus on PHP internals) | ||
===== Changelog ===== | ===== Changelog ===== | ||
- | 2012-10-17: Initial version. | + | * 2012-11-09: Explain a minor configuration change possibility to harmonize this proposal with the one for nginx. |
+ | * 2012-10-18: Integrate discussion items from the PHP internals list. | ||
+ | * 2012-10-18: Patches added. | ||
+ | * 2012-10-17: Initial version. |
rfc/socketactivation.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1