rfc:socketactivation
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:socketactivation [2012/10/18 02:56] – add usage summary davidstrauss | rfc:socketactivation [2012/10/18 23:29] – [What about Upstart support?] davidstrauss | ||
---|---|---|---|
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 27: | Line 36: | ||
===== Usage for end-users ===== | ===== Usage for end-users ===== | ||
- | 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 and logs to be aggregated | + | 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 |
- | 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 48: | Line 57: | ||
Group=my-php-fpm-pool | Group=my-php-fpm-pool | ||
ExecStart=/ | ExecStart=/ | ||
- | KillMode=process'' | + | KillMode=process |
</ | </ | ||
Line 68: | Line 77: | ||
</ | </ | ||
+ | ==== 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 (<1% per | ||
+ | service, but it adds up when you manage 500+ pools on a box) when not | ||
+ | processing requests. | ||
+ | |||
+ | The ondemand process manager doesn' | ||
+ | mentioned earlier (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 | ||
+ | " | ||
+ | |||
+ | ==== 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. | ||
===== Changelog ===== | ===== Changelog ===== | ||
- | 2012-10-17: Initial version. | + | * 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