Summary: | app-eselect/eselect-php - php-fpm init script SLOT pid file conflicts | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jaco Kroon <jaco> |
Component: | Current packages | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | CC: | mjo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=632690 https://bugs.gentoo.org/show_bug.cgi?id=910589 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jaco Kroon
2020-12-23 06:05:57 UTC
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. |