tl;dr app-eselect/eselect-php should run php-fpm in foreground and use start-stop-daemon to background the service. Proposed changes: diff -rupN old/eselect-php/files/php-fpm-r1.init new/eselect-php/files/php-fpm-r1.init --- old/app-eselect/eselect-php/files/php-fpm-r1.init 2015-03-31 18:53:51.000000000 +0200 +++ new/app-eselect/eselect-php/files/php-fpm-r1.init 2015-04-29 19:50:30.279466580 +0200 @@ -22,7 +22,7 @@ depend() { start() { ebegin "Starting PHP FastCGI Process Manager" set_phpvars - start-stop-daemon --start --pidfile ${PHP_FPM_PID} --exec \ + start-stop-daemon --start --background --pidfile ${PHP_FPM_PID} --exec \ /usr/lib/${PHPSLOT}/bin/php-fpm -- -y "${PHP_FPM_CONF}" -g "${PHP_FPM_PID}" local i=0 local timeout=5 Please check if we also want to pass something like "--nodaemonize". The problem: ============ You cannot use Python's subprocess module to start/restart php-fpm when you have set error_log = syslog in /etc/php/fpm-php*/php.ini How to reproduce: ================ Use the Python code from http://bugs.python.org/issue23213#msg233788 or use app-admin/salt to reproduce: 1) Install dev-lang/php and app-eselect/eselect-php[fpm] 2) Set "error_log = syslog" in /etc/php/fpm-php*/php.ini 3) # emerge app-admin/salt 4) # salt-call service.restart php-fpm salt or Python will now hang forever. `ps fauxw` will list you something like root 57313 0.1 0.2 386100 71932 pts/4 Sl+ 19:45 0:01 \_ /usr/bin/python2.7 /usr/lib/python-exec/python2.7/salt-call root 57334 0.0 0.0 0 0 pts/4 Z+ 19:45 0:00 \_ [php-fpm] <defunct> Background: =========== I am managing multiple Gentoo systems with app-admin/salt (Python-based configuration management tool). I saw this problem the first time after I updated PHP and had to restart php-fpm. But doing a bisect for php wasn’t that easy. Some weeks later I experienced the same problem with udev (when sys-fs/udev was bumped to v217). Fortunately, bisecting udev wasn’t that hard and I found the commit which introduced the problem: commit 5c67cf2774a8b964f4d7cd92a4c447da81ac6087 Date: Fri Sep 12 16:22:44 2014 +0200 udev: don't close std{in,out,err} Rather than printing debug output to stderr and redirecting this to /dev/null when not wanted, use the correct log_*() function in the first place. From: https://github.com/systemd/systemd/commit/5c67cf2774a8b964f4d7cd92a4c447da81ac6087 I filled a bug for salt (https://github.com/saltstack/salt/issues/14957) and Python (http://bugs.python.org/issue23213) but wasn’t sure if this is upstream related or not. Last week I read about bug 498684 and tried the fixed start-stop-daemon again. Well, it doesn’t work out of the box because the runscripts don’t use start-stop-daemon’s "--background" option at the moment. Solution: ========= udevd and php-fpm (when using error_log = syslog) don’t close their handlers for std* (so this is not Python-related!). This will keep the terminals open forever. When using "start-stop-daemon --background ..." to start/stop these services, we won't run into the problem described above. I am not sure if this isn’t something upstream should fix, but due to the ongoing systemd movement and all the services running in foreground these days using start-stop-daemon's background feature seems to be valid solution for me. I filled the same bug for sys-fs/udev-init-scripts which got accepted, see bug 547916. Without the patch: # /etc/init.d/php-fpm restart * Caching service dependencies ... [ ok ] * Stopping PHP FastCGI Process Manager ... [ ok ] * Starting PHP FastCGI Process Manager ... [NOTICE] [pool www] pm.start_servers is not set. It's been set to 20. [ ok ] srv2 ~ # for i in /proc/$(pgrep -U root php-fpm)/fd/*; do echo $i $(readlink $i); done /proc/58602/fd/0 /dev/null /proc/58602/fd/1 /dev/null /proc/58602/fd/2 /dev/pts/4 /proc/58602/fd/3 /tmp/.ZendSem.wd5Io7 (deleted) /proc/58602/fd/4 socket:[207377] /proc/58602/fd/5 socket:[206140] /proc/58602/fd/7 socket:[206141] /proc/58602/fd/8 socket:[206142] /proc/58602/fd/9 anon_inode:[eventpoll] With the patch (and OpenRC-0.14, required due to bug 498684): # /etc/init.d/php-fpm restart * Caching service dependencies ... [ ok ] * Stopping PHP FastCGI Process Manager ... [ ok ] * Starting PHP FastCGI Process Manager ... [ ok ] srv2 ~ # for i in /proc/$(pgrep -U root php-fpm)/fd/*; do echo $i $(readlink $i); done /proc/58902/fd/0 /dev/null /proc/58902/fd/1 /dev/null /proc/58902/fd/2 /dev/null /proc/58902/fd/3 /tmp/.ZendSem.XS16vc (deleted) /proc/58902/fd/4 socket:[207516] /proc/58902/fd/5 socket:[206205] /proc/58902/fd/7 socket:[206206] /proc/58902/fd/8 socket:[206207] /proc/58902/fd/9 anon_inode:[eventpoll]
In PHP it is only stderr which won't be closed when running with "error_log = syslog".
I created a bug in upstream's bug tracker (https://bugs.php.net/bug.php?id=69865) due to the fact that the similar bug 547916 was fixed by upstream.
Does this fix it for you? https://github.com/m6w6/php-src/commit/469ec0d478073627654f853a5eed4c52faca0796 My instinct says that's probably the right place for a fix since php-fpm is daemonizing itself. All of these old unix programming books say that the process should attach the three inherited std* descriptors to something like /dev/null.
Yes, this fixes the problem for me.
This is fixed upstream (see $url) and will make its way into a release eventually.
