Bug #68440 [NEW]: ERROR: failed to reload: execvp() failed: Argument list too long (7)
| From: | a23878941 at gmail dot com | 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