Re: [RFC] Single binary for CLI and FPM

On Thu, 08 Oct 2026 14:25:14 +0000, tim@bastelstu.be wrote: > Hi > > On 2026-10-08 15:53, Matthieu Napoli wrote: > > Right, good point, I agree too, thanks! > > > > I opened a new PR that goes the other way around: > > https://github.com/php/php-src/pull/24192 > > > > I have also updated the RFC: > > https://wiki.php.net/rfc/single-binary-cli-fpm > > > > - php CLI is unchanged > > - php-fpm *always* includes > > php (and runs as CLI when run as php > > instead of php-fpm) > > - no need for a build option anymore > > - the diff is simpler > > - FPM aligns with FrankenPHP (both include the CLI) > > - No --fpm CLI option anymore, solves the objections > > raised > > previously in this thread > > > > That sounds much better indeed. > > I disagree that this is better from a discoverability and predictability > point of view and I also disagree with the concerns that the original > proposal would somehow “privilege” FPM. > > As for the first part: > > When running a PHP binary on the command line, my expectation is that > I'm running a CLI application and thus I expect to end up in the CLI > SAPI. Suddenly starting FPM, which potentially binds ports or sockets, > just because I happen to name the binary the wrong name (e.g. when using > a custom p symlink to run PHP after my distro switched to the > “combined binary” setup or just php-8.7 that the RFC notes > as running > FPM) would be very surprising. With the current proposal I also have no > way out, except naming the binary differently. Changing behavior based > on the binary name to do entirely different things is something that is > comparatively rarely used and thus folks are unlikely to be accustomed > to this being a thing (the most prominent example that comes to mind > would be Busybox). An explicit flag / argument would be properly > discoverable (appearing in help outputs) and would also be reliably > scriptable. > > For the second point, and tying into the first: PHP FPM is a / the > recommended solution of running PHP as a FastCGI application. Adding an > --fpm flag to the PHP binary to run PHP in “FastCGI mode” > would match > the -S flag to run PHP in “HTTP mode” (which switches from > the cli > to the cli-server SAPI). I understand that the current “HTTP > mode” > implementation is meant to be used for development purposes only, but > that is an implementation detail. We could in theory implement a > production grade web server to PHP tomorrow (and potentially add > --http as the entrypoint for the “HTTP mode”, keeping > -S as an > alias) and then we would have: > > php # CLI mode > php --fpm # FastCGI mode > php --http # HTTP mode > > with the php binary being the singular entrypoint for all use > cases > where PHP is running “standalone” rather than embedded into something > else (as with mod_php). Alternatively, we use --mode=fpm to > switch to > FPM mode instead of reserving the top level --fpm flag. > > Best regards > Tim Düsterhus I agree with Tim here, for three reasons: - ergonomically, using php --fpm <fpm-args> is clearer than being forced to rename the binary (I only suggested that it's a possibility for build maintainers) - php-fpm usually lives in /usr/sbin which usually shouldn't be accessed directly by users - even if we ignore that, php-fpm php-cli <cli-args> is silly I don't share Larry's concern here, I don't see FrankenPHP completely replacing FPM any time soon. There has to remain a way to run php without locking ourselves to Go (and realistically Caddy). But even if it did, dropping a --fpm flag is no different than dropping a php-fpm target. (Since php --fpm, maybe php --http, or even php --le-monstre ;) are where it would end anyway, so I see no reason to gate it behind a dedicated --mode= flag) Kind regards Marc Henderkes