> This means scripts running in a FPM web context and relying on `PHP_BINARY` cannot spawn fresh FPM instances (for whatever reason), without adding a `--fpm` flag themselves.
Right, though starting a new FPM master from a script running _inside_ FPM already seems rare to me, and such code would need to know the FPM setup (config file, etc.). The opposite case is more common though (scripts in FPM that use `PHP_BINARY` to run CLI commands. The RFC would make that simpler. If there is a real need, I see two simpler options: - `php-fpm` could ignore `--fpm` so that `PHP_BINARY --fpm ...` always work - if embedding FPM is the default, then `PHP_BINARY --fpm ...` should work in most cases then > The RFC also notes that the standalone PHP FPM binary will remain an option. > Is there any reason to keep support for that, except for backward > compatibility? No. I'd find this preferable to drop `php-fpm` in a separate step/RFC since that's a fairly big breaking change for packagers. Matthieu
