dev-lang/php[fpm] provide /etc/init.d/php-fpm but there is no service file for systemd Reproducible: Always
php-5.5.0_rc2 has --with-fpm-systemd, which I plan on adding support for under the systemd USE flag. What is the cleanest way of handling the unit file? I am thinking that it must be in the eselect-php package so it can handle multiple slots. But that means a systemd USE flag there as well since eselect-php should only be aware of fpm-installs with systemd support. Does anyone have any other alternatives?
*** Bug 474548 has been marked as a duplicate of this bug. ***
I added preliminary support for systemd now, but it is not as good as I would like it to be. Most notably, it does not respect what you set as default fpm verion, you have to explicitly set it as the service's instance name.
*** Bug 479816 has been marked as a duplicate of this bug. ***
Systemd support was included in the php-5.5.3-r1.ebuild but was removed again in the more recent ebuilds without a notice in the Changelog. Maybe they just took an older ebuild as template for the newer ones. The problem is that the included systemd unit which gets still installed despite the now missing systemd useflag sets the service type to "notify" which makes php-fpm startup hang until timeout and gets it killed afterwards because without compiled in systemd support using "--with-fpm-systemd" php-fpm will not send the startup notification to systemd's notification socket. So please either readd systemd support to php or set the systemd service type to "forking".
(In reply to Thomas Scheiblauer from comment #5) > Systemd support was included in the php-5.5.3-r1.ebuild but was removed > again in the more recent ebuilds without a notice in the Changelog. Maybe > they just took an older ebuild as template for the newer ones. > The problem is that the included systemd unit which gets still installed > despite the now missing systemd useflag sets the service type to "notify" > which makes php-fpm startup hang until timeout and gets it killed afterwards > because without compiled in systemd support using "--with-fpm-systemd" > php-fpm will not send the startup notification to systemd's notification > socket. > So please either readd systemd support to php or set the systemd service > type to "forking". Systemd "support" only existed for ~arch, so it is not something that is very urgent for us to fix right now.
It's not for me, I added systemd support back by myself in my local overlay. But you could at least set the Type property in the systemd unit "php-fpm@.service" file set to "forking", which is an easy fix, to not leave the systemd "~arch" people with an obviously broken ebuild. Btw, sys-apps/systemd-204-r1 and dev-lang/php-5.5.4 are already in "arch" so also the stable systemd users would run into this problem, at least when the use nginx with php-fpm.
(In reply to Thomas Scheiblauer from comment #7) > It's not for me, I added systemd support back by myself in my local overlay. > But you could at least set the Type property in the systemd unit > "php-fpm@.service" file set to "forking", which is an easy fix, to not leave > the systemd "~arch" people with an obviously broken ebuild. > Btw, sys-apps/systemd-204-r1 and dev-lang/php-5.5.4 are already in "arch" so > also the stable systemd users would run into this problem, at least when the > use nginx with php-fpm. If you use systemd, you cannot use any current version of PHP. None of our versions support systemd even if unstable eselect-php ships a unit file.
I've readded the systemd support to php-5.5.6 (just copied a few lines from php-5.5.3-r1) and it works superbly with systemd.service type "notify" as used in eselect-php's systemd unit file. In essence it's nothing more than adding "--with-fpm-systemd" to the configure options.
I'm using systemd and the same patch has been working fine for me with PHP 5.4.x in the last 3-4 months (see attachment of bug #479816). I don't understand why it has been removed. Is there any problem with the patch?
(In reply to Ole Markus With from comment #1) > php-5.5.0_rc2 has --with-fpm-systemd, which I plan on adding support for > under the systemd USE flag. > > What is the cleanest way of handling the unit file? > > I am thinking that it must be in the eselect-php package so it can handle > multiple slots. But that means a systemd USE flag there as well since > eselect-php should only be aware of fpm-installs with systemd support. > > Does anyone have any other alternatives? Why not simply make each dev-lang/php slot provide a php-${SLOT}.service file? (without relying in eselect)
As a member of the systemd team and a light user of php: I think eselect-php is the wrong place for this. I would instead install php-fpm-${SLOT}.service in the dev-lang/php ebuild. Also, the service unit should not contain Type=notify if the systemd use flag is disabled on dev-lang/php. There are 2 alternate solutions: 1. Change Type=notify to Type=simple if USE=systemd is disabled. 2. Don't install the unit file if USE=systemd is disabled.
In bug 488540 also okias suggests to use "--nodaemonize" that will let to drop all the PID handling and would be preferred too
Anyway, in this moment this isn't enhancement, but major _fuckup_, because when you install PHP, you'll be not able run php-fpm@5.5 in ANY condition WITHOUT modifying service. It's big waste of time for people using systemd (OFFICIALY supported by upstream, disabled by gentoo and replaced by non-working file) and solution is already found. Where is problem fixing this issue?
In general: no stable ebuild of php had systemd support, so pulling systemd support from php is not a regression of any sort. I can delete the eselect-php versions shipping the unit files if this is such a big problem. For now, I have no plans on working more with systemd. It is a significantly higher priority to prepare the tree for php 5.6, which is entering testing soon.
We (systemd team) could work on the unit files for php if needed, but, as explained, we would opt by the units being provided by php ebuilds and different for each slot. What do you think?
(In reply to Pacho Ramos from comment #16) > We (systemd team) could work on the unit files for php if needed, but, as > explained, we would opt by the units being provided by php ebuilds and > different for each slot. What do you think? That is absolutely fine by me :)
All reworked in latest revisions
i patched php 5.5.12 with php-5.5.11-systemd.patch and it works fine. don't use fpm so donno about that. thanks!
