Summary: | dev-lang/php-5.5.19 USE="fpm" - reloading php-fpm fails: ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tomáš Mózes <hydrapolic> |
Component: | [OLD] Development | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=530820 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tomáš Mózes
2014-12-01 16:25:37 UTC
Did you create an upstream bug for this? It does not look to be a Gentoo-related issue. I just tested php-5.5.20_rc1 on amd64, it works ok on both, older machines that got updated to current (except for gcc 4.7) and brand new machines with gcc 4.8. Checking the NEWS for 5.5.20_rc1, it has lots of php-fpm fixes: 27 Nov 2014, PHP 5.5.20RC1 - Core: . Fixed bug #68091 (Some Zend headers lack appropriate extern "C" blocks). (Adam) . Fixed bug #68185 ("Inconsistent insteadof definition."- incorrectly triggered). (Julien) . Fixed bug #68370 ("unset($this)" can make the program crash). (Laruence) - FPM: . Fixed bug #68381 (fpm_unix_init_main ignores log_level). (David Zuelke, Remi) . Fixed bug #68420 (listen=9000 listens to ipv6 localhost instead of all addresses). (Remi) . Fixed bug #68421 (access.format='%R' doesn't log ipv6 address). (Remi) . Fixed bug #68423 (PHP-FPM will no longer load all pools). (Remi) . Fixed bug #68428 (listen.allowed_clients is IPv4 only). (Remi) . Fixed bug #68452 (php-fpm man page is oudated). (Remi) . Fixed request #68458 (Change pm.start_servers default warning to notice). (David Zuelke, Remi) . Fixed bug #68463 (listen.allowed_clients can silently result in no allowed access). (Remi) . Fixed request #68391 (php-fpm conf files loading order). (Florian Margaine, Remi) . Fixed bug #68478 (access.log don't use prefix). (Remi) - PDO_pgsql: . Fixed bug #66584 (Segmentation fault on statement deallocation) (Matteo) . Fixed bug #67462 (PDO_PGSQL::beginTransaction() wrongly throws exception when not in transaction) (Matteo) . Fixed bug #68351 (PDO::PARAM_BOOL and ATTR_EMULATE_PREPARES misbehaving) (Matteo) - zlib: . Fixed bug #53829 (Compiling PHP with large file support will replace function gzopen by gzopen64) (Sascha Kettler, Matteo) The problem with this is the set_phpvars() function, specifically how it sets the PHP_FPM_PID option. Regardless of what is set there, the php-fpm pid file is put into /run/php-fpm rather than /run/, so the openrc checks always go mental. Fixing this is straight forward. Apply this little patch to /etc/init.d/php-fpm 5c5 < PHP_FPM_PID="/run/php-fpm/php-fpm-${PHPSLOT}.pid" --- > PHP_FPM_PID="/run/php-fpm-${PHPSLOT}.pid" 8c8 < PHP_FPM_PID="/run/php-fpm/php-fpm.pid" --- > PHP_FPM_PID="/run/php-fpm.pid" This allows me to restart fpm normally, which was causing hell with puppet. Eric, which version do you have installed? When I check the init script in version 5.5.19, it already looks like that: set_phpvars() { PHPSLOT=${SVCNAME#php-fpm-} PHP_FPM_PID="/run/php-fpm-${PHPSLOT}.pid" if [ ${PHPSLOT} = 'php-fpm' ] ; then PHPSLOT="$(eselect php show fpm)" PHP_FPM_PID="/run/php-fpm.pid" fi PHP_FPM_CONF="/etc/php/fpm-${PHPSLOT}/php-fpm.conf" } I'm not sure this bug is the related, but I have a problem: I have 8 pool declared in php-fpm config. I start the php-fpm server, I have no error message, not in the log. Reload works, restart works, but only the first 2 pool is started! Yes, I mean, the first two, if i change the order of pools in the fpm config, the first two will listen on the defined ports (netstat -ltpn). Any package reemerge didn't help, downgradeing to 5.5.18 solved the problem. Upgrading to 5.5.20 fixed the issue. (In reply to Tomas Mozes from comment #6) > Upgrading to 5.5.20 fixed the issue. Relevant information: https://bugs.php.net/bug.php?id=68423 (In reply to László Szalma from comment #7) > (In reply to Tomas Mozes from comment #6) > > Upgrading to 5.5.20 fixed the issue. > > Relevant information: > > https://bugs.php.net/bug.php?id=68423 5.5.20 committed to the tree |