Recently I've updated from php 8.1 to 8.2, removed 8.1 Ran eselect php set fpm 1 ( since 1 was the only one and it was 8.2 ) Then ran /etc/init.d/php-fpm restart It yelled /etc/init.d/php-fpm: line 61: /usr/lib64/php8.1/bin/php-fpm: No such file or directory [!!] Further debug on IRC got to a /run/openrc/options/php-fpm/PHP_SLOT which still said 8.1 Doing /etc/init.d/php-fpm stop then /etc/init.d/php-fpm start worked. eselect should recommend stopping and starting the fpm when changing.
Just to add some more background: we had some fun debugging this on IRC. This behaviour was introduced, I think, by the changes for bug 910589. service_get_value is used which means you get *different* behaviour between /etc/init.d/php-fpm restart and /etc/init.d/php-fpm stop and then /etc/init.d/php-fpm start. navi and I spoke about it as well and we're not really sure if that's intentional or if such persistence should only apply to e.g. reload.
Created attachment 910988 [details] ULS's variation of the php-fpm script I can't comment for others, but this is the init script that works for us, as per the bug Sam referenced we had similar frustrations. This was based off of the original gentoo init script.
Yeah, sorry. Managing the active slot with OpenRC is... not ideal. There's more discussion on bug 761319, but I opened bug 632690 now seven years ago to fix it. The init script has to manage a daemon that can't change on-the-fly. Instead of having one script for all versions of PHP, we should have one script for each PHP. This is how most other slotted daemons work, and it would let us upstream the OpenRC scripts so that we don't have to ship them as part of eselect-php (which is already weird).
