php-fpm failed to start via systemd: # systemctl status php-fpm@5.5 php-fpm@5.5.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib64/systemd/system/php-fpm@.service; enabled) Active: failed (Result: timeout) since Sat 2013-10-19 10:10:25 CST; 9min ago Main PID: 10393 10月 19 10:08:55 timemars systemd[1]: Starting The PHP FastCGI Process Manager... 10月 19 10:10:25 timemars systemd[1]: php-fpm@5.5.service operation timed out. Terminating. 10月 19 10:10:25 timemars systemd[1]: Failed to start The PHP FastCGI Process Manager. 10月 19 10:10:25 timemars systemd[1]: Unit php-fpm@5.5.service entered failed state. Well, actually I notice that systemd USE flag was added to php-5.5.1-r1 for the first time, and missed in the following version bumps, except readded in php-5.5.3-r1, as a revision bump. Is systemd support for php-fpm still considered to be unstable right now? Or you guys just forget it?
Please note: > Ebuilds must not introduce USE=systemd in order to control unit file installation. Unit files do not require systemd installed, and follow the usual guidelines against small text files (bash completion, logrotate etc.). (http://wiki.gentoo.org/wiki/Systemd/Ebuild_policy) But regardless of that, it should indeed not terminate like that; can you look into the logs (journalctl / PHP specific logs) if you can see more information?
What systemd version are you using? Is this a regression for your case compared with 5.5.4?
The systemd USE flag made PHP build against libsystemd, so it is not only about the unit file. Without PHP being compiled against systemd the unit file does not work properly, which is why it hangs. The systemd feature for PHP is indeed unstable and I am not adding it to a stable version until someone who knows systemd better than me answers the question in bug 439918.
(In reply to Tom Wijsman (TomWij) from comment #1) > Please note: > > > Ebuilds must not introduce USE=systemd in order to control unit file installation. Unit files do not require systemd installed, and follow the usual guidelines against small text files (bash completion, logrotate etc.). > > (http://wiki.gentoo.org/wiki/Systemd/Ebuild_policy) > > But regardless of that, it should indeed not terminate like that; can you > look into the logs (journalctl / PHP specific logs) if you can see more > information? In fact the unit file is installed by eselect-php: # equery b /usr/lib/systemd/system/php-fpm@.service * Searching for /usr/lib/systemd/system/php-fpm@.service ... app-admin/eselect-php-0.7.1-r2 (/usr/lib/systemd/system/php-fpm@.service) USE=systemd in php is to make php-fpm started via systemctl, thus it does not violate the ebuild policy.
(In reply to Ole Markus With from comment #3) > The systemd USE flag made PHP build against libsystemd, so it is not only > about the unit file. > > Without PHP being compiled against systemd the unit file does not work > properly, which is why it hangs. > > The systemd feature for PHP is indeed unstable and I am not adding it to a > stable version until someone who knows systemd better than me answers the > question in bug 439918. So I have to edit the ebuild to make it build against systemd if I want to use php-fpm in a systemd system?
Well, I spending some time and it's still broken today. -- Unit php-fpm@5.5.service has begun starting up. Jan 11 00:04:11 leonix systemd[1]: php-fpm@5.5.service operation timed out. Terminating. [11-Jan-2014 00:02:41] NOTICE: fpm is running, pid 13082 [11-Jan-2014 00:02:41] NOTICE: ready to handle connections [11-Jan-2014 00:04:11] NOTICE: Terminating ... [11-Jan-2014 00:04:11] NOTICE: exiting, bye-bye! To be honest, I'm pretty pissed! (don't take it personally)
Change to this systemd file helped me. It's probably just workaround, but it works [Unit] Description=The PHP FastCGI Process Manager After=network.target [Service] #Type=notify #PIDFile=/run/php-fpm/php-fpm-%I.pid ExecStart=/usr/libexec/php-fpm-launcher php%I -y /etc/php/fpm-php%I/php-fpm.conf --nodaemonize ExecReload=/bin/kill -USR2 $MAINPID #PrivateTmp=true Restart=always [Install] WantedBy=multi-user.target
The options I see: - Make dev-lang/php provide the service files for their slot - Add a "systemd" USE to app-admin/eselect-php to install the service file only when php[systemd] dependency is satisfied
(In reply to Ole Markus With from comment #3) > The systemd USE flag made PHP build against libsystemd, so it is not only > about the unit file. > > Without PHP being compiled against systemd the unit file does not work > properly, which is why it hangs. > > The systemd feature for PHP is indeed unstable and I am not adding it to a > stable version until someone who knows systemd better than me answers the > question in bug 439918. A better interim solution would be to add it to package.use.mask or package.use.stable.mask. Dropping the flag from the ebuild completely is just confusing to people.
Created attachment 367604 [details] php-fpm systemd unit using Type=simple rather than Type=notify The systemd unit uses sd_notify() (the systemd way to let daemons tell the init system that they are *really* ready to receive traffic), because of Type=notify. However if you don't compile dev-lang/php with USE=systemd, sd_notify() will not be called by the php-fpm daemon, thus the systemd unit times out. Ironically, you can even change the php-fpm configuration to use unix domain sockets rather than tcp sockets and this code path, at least in the version I tried a few months ago, doesn't call sd_notify() (yeah, that's a php bug!) so the unit fails anyway. So, we should either switch back to the classic Type=simple (see the attached unit) or make clear how the systemd unit works. This systemd unit also works with php-fpm-5.3, which doesn't support sd_notify().
(In reply to Fabio Erculiani from comment #10) > Created attachment 367604 [details] > php-fpm systemd unit using Type=simple rather than Type=notify > > The systemd unit uses sd_notify() (the systemd way to let daemons tell the > init system that they are *really* ready to receive traffic), because of > Type=notify. However if you don't compile dev-lang/php with USE=systemd, > sd_notify() will not be called by the php-fpm daemon, thus the systemd unit > times out. > Ironically, you can even change the php-fpm configuration to use unix domain > sockets rather than tcp sockets and this code path, at least in the version > I tried a few months ago, doesn't call sd_notify() (yeah, that's a php bug!) > so the unit fails anyway. I couldn't find any bug [1]. I guess it will work, because no bugs are filled and most of distributions use systemd, so probably someone notice. OR it's fixed in 5.5.7/8 (but changelog not mention it). [1] https://bugs.php.net/search.php?cmd=display&search_for=systemd&x=0&y=0 > > So, we should either switch back to the classic Type=simple (see the > attached unit) or make clear how the systemd unit works. > This systemd unit also works with php-fpm-5.3, which doesn't support > sd_notify(). I propose for < 5.5.0 OR (5.5.0 without systemd) use simple, otherwise use notify. Does it look sane?
All reworked in latest revisions
