+# An open question is, what should we do if the user has both a +# slot-agnostic and slotted init script, which happen to point to the +# same slot? In other words, if the user has a php-fpm init script and +# slot php7.1 eselected, but also a php-fpm-php7.1 init script. Should +# they manage the same instance? I think so... And I think not. So here is the changes that we make to the current default php-fpm init script: We set: pidfile="/run/${RC_SVCNAME}.pid" (instead of "/run/php-fpm-${SLOT}.pid") Our motivation for this one is to in a hosting environment either set the PHP version for an instance to the "system version", or pin it on a specific version. We have upwards of 500 instances in most of the environments we run. Secondly, we also comment this out: #PHP_FPM_CONF="/etc/php/fpm-${PHP_SLOT}/php-fpm.conf" Instead preferring to set this from conf.d, as we stoe that on a shared filesystem not under /etc/ ... we can probably symlink that, but in light of requirement for 1, this ends up not working so well (two slots that should reference two different config files). Thinking about this, there is no single "fit all" default, so perhaps simply only set the above, if it's not already set from conf.d file, something like: [ -z "${PHP_FPM_CONF}" ] && PHP_FPM_CONF="/etc/php/fpm-${PHP_SLOT}/php-fpm.conf" Or: PHP_FPM_CONF="${PHP_FPM_CONF:-/etc/php/fpm-${PHP_SLOT}/php-fpm.conf}" Whilst both achieve the same thing, the latter is more compact but the former is more readable (in my opinion). Reproducible: Always
This is related to the larger issue (bug 632690) of whether or not we should have an eselected php-fpm in the first place. I think not, since eliminating that SLOT magic would allow us to simplify and upstream our service script. In that case, pidfile="@piddir@/${RC_SVCNAME}.pid" would be correct, and if you wanted to run multiple instances of the same version, you could do it with symlinks similar to how network interfaces are handled.
(In reply to Michael Orlitzky from comment #1) > This is related to the larger issue (bug 632690) of whether or not we should > have an eselected php-fpm in the first place. I think not, since eliminating > that SLOT magic would allow us to simplify and upstream our service script. Interesting question. So I've been wondering about this too over the last while, at least in "does it make sense". For our use cases, we settled on "yes, it's good that we have a default that tracks the newest installed version", so our update systems use eselect to automatically change php slot version to the newest, and this ends up updating 90% of our users automatically. We can then choose to pin a specific consumer of php-fpm to a specific version. If you're referring purely to the SLOT HANDLING in the init script, I agree, that should completely go away if possible. > In that case, > > pidfile="@piddir@/${RC_SVCNAME}.pid" IMHO this is good even now. > would be correct, and if you wanted to run multiple instances of the same > version, you could do it with symlinks similar to how network interfaces are > handled. And the changes I proposed allows that right now, even with an eselect slot. Perhaps the default config can be located based RC_SVCNAME too ... we still want the ability to override that from conf.d/ which does slightly complicate it. If you're open to the idea, I'll be happy to post an updated init.d script for you here?
I'm not opposed to it. In the long run I think pidfile="@piddir@/${RC_SVCNAME}.pid" is the way to go, but I may not be the best one to predict any practical problems since I use mod_php (and not php-fpm) for everything. One caveat is that all existing services should be stopped before installing the new service script. Otherwise, once the new script is installed, running "stop" will try to kill the PID in a pidfile that doesn't exist; the name was different when the service was started and the pidfile was created. I think $PHP_FPM_CONF should ultimately involve $RC_SVCNAME instead of $PHP_SLOT as well. If we drop the SLOT magic and move the service scripts upstream, you could still have one service that runs the "latest" version... you would just have to create a link from e.g. /etc/init.d/latest to /etc/init.d/$version, and then symlink all of your actual instances to /etc/init.d/latest. Then when a new version is released, you would change only where /etc/init.d/latest points. (Basically you would replace "eselect php fpm..." by the creation of a new symlink. In fact, "eselect php fpm" could be made to manage that symlink for you.) In any case, the big picture: there are a lot of little painful changes necessary to clean things up. I would prefer it if they all took place at the same time in a new release of eselect-php and dev-lang/php with upstreamed OpenRC scripts, but I'll understand if you don't want to undertake that larger task. I haven't gotten around to it in three years either. The repo for the existing script is here BTW: https://gitweb.gentoo.org/proj/eselect-php.git
(In reply to Michael Orlitzky from comment #3) > In any case, the big picture: there are a lot of little painful changes > necessary to clean things up. I would prefer it if they all took place at > the same time in a new release of eselect-php and dev-lang/php with > upstreamed OpenRC scripts, but I'll understand if you don't want to > undertake that larger task. I haven't gotten around to it in three years > either. Do you have a list? Perhaps I can at the very least take a look. Kind Regards, Jaco
(In reply to Jaco Kroon from comment #4) > > Do you have a list? > Sorry, I forgot about this =) Off the top of my head... 1. Drop the SLOT handling from the php-fpm OpenRC service script in the eselect-php repo so that it can be upstreamed. 2. Create a PR against upstream PHP that adds the resulting service script to their build tree, likely alongside the upstream systemd service script. You'll need to tell configure.ac to substitute the @bindir@ etc. variables into it. 3. Drop the php-fpm service scripts from eselect-php and its ebuilds entirely. 4. Modify "eselect-php set fpm..." to create a symlink at /etc/init.d/php-fpm pointing to whatever specific version of the init script that the user asked for. 5. Modify the dev-lang/php ebuilds to depend on the new version of eselect-php, to use the patch from your PR, and to build/install one copy of the service script for each slot. We already do this for the systemd service scripts, so it should be straightforward.
We forked and rolled our own init script, the last batch of updates went in completely the wrong direction for us and made things far, far worse for us, but we get the motivation behind those changes. We have converted all our systems to use our own php-fpm init script that behaves the way we need/want it to.
