Bug #68440 [NEW]: ERROR: failed to reload: execvp() failed: Argument list too long (7)

From: Date: Tue, 18 Nov 2014 01:49:25 +0000
Subject: Bug #68440 [NEW]: ERROR: failed to reload: execvp() failed: Argument list too long (7)
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-188649@lists.php.net to get a copy of this message
From: a23878941 at gmail dot com Operating system: CentOS 6.6 PHP version: 5.4.35 Package: FPM related Bug Type: Bug Bug description:ERROR: failed to reload: execvp() failed: Argument list too long (7) Description: ------------ When PHP-FPM is reloaded via a command like "service php-fpm reload", php-fpm goes down and does not start back up. The following error appears in the log. ERROR: failed to reload: execvp() failed: Argument list too long (7) When debug logging is enabled the error below appears. ERROR: pid 9550, fpm_pctl_exec(), line 102: failed to reload: execvp() failed: Argument list too long (7) Problem only started happening after using more than around 2,600 pools. Problem did not happen with less pools. Problem went away after decreasing the number of pools to below that range. Problem does not happen when php-fpm is simply stopped and started or restarted (i.e. service php-fpm restart). Problem only happens during a reload (i.e. service php-fpm reload). Problem noticed under CentOS 6.6 and PHP 5.3.3. However, I assume problem happens in more recent PHP versions because I can find no evidence of prior bug reports where this has been fixed. Have not been able to test with more recent PHP version. Running "kill -USR2 [php-fpm pid]" causes the same problem as "service php-fpm reload". Using unix sockets and ondemand pm for all pools. Each pool name, corresponding conf file name, and unix socket name is rather long (e.g. 20-40 characters). I don't know if this is related to problem or not. I have not tried shortening pool names to work around problem. Concerning workarounds, increasing stack size (e.g. via ulimit -s) in order to increase ARG_MAX did not solve problem. Research shows that MAX_ARG_STRLEN might be a limiting factor also. Was not able to find a way to increase MAX_ARG_STRLEN. Thanks for any help! -- Edit bug report at https://bugs.php.net/bug.php?id=68440&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=68440&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=68440&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=68440&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=68440&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=68440&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=68440&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=68440&r=needscript Try newer version: https://bugs.php.net/fix.php?id=68440&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=68440&r=support Expected behavior: https://bugs.php.net/fix.php?id=68440&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=68440&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=68440&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=68440&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=68440&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=68440&r=dst IIS Stability: https://bugs.php.net/fix.php?id=68440&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=68440&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=68440&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=68440&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=68440&r=mysqlcfg

« previous php.bugs (#188649) next »