Bug 632690 – app-eselect/eselect-php: upstream the php-fpm OpenRC service script

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Michael Orlitzky 2017-10-02 12:03:23 UTC]

Currently our php-fpm service script supports slotting in the script itself. If the service script is named "php-fpm" -- which it is by default -- then it will start/stop/reload the eselected version of php-fpm. However, if the service script is named e.g. php-fpm-5.6, then it will only manage the 5.6 slot of php-fpm.

To accommodate all of that, there's some slot handling code at the top of the script:

  PHP_SLOT="${SVCNAME#php-fpm-}"
  if [ "${PHP_SLOT}" = "php-fpm" ] ; then
      PHP_SLOT="$(eselect php show fpm)"
  fi

That makes our service script non-portable, since other distributions don't do slotting, and won't have the "eselect" command available.

A smarter way to do this is the same way postgresql does it: create one service script per slot, and let the user decide which one to use. That would let us eliminate the slot-handling code from our service script, making it portable enough to upstream into dev-lang/php. The @variable@ substitutions would be handled by the dev-lang/php build system, and then we would install the service script with e.g.

  newinitd sapi/fpm/openrc.init "php-fpm-${SLOT}"

Having the php-fpm service script installed by the same package that installs php-fpm would also be less weird than the situation we have now, where eselect-php installs the init script for another package.

[Comment 1 Michael Orlitzky 2017-12-10 15:41:19 UTC]

FWIW, our systemd service scripts do the same thing. And there is already an upstream php-fpm.service that we might be able to use if we installed one copy per slot.