php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68440 ERROR: failed to reload: execvp() failed: Argument list too long (7)
Submitted: 2014-11-18 01:49 UTC Modified: 2018-03-30 16:49 UTC
Votes:4
Avg. Score:4.2 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:1 (25.0%)
From: a23878941 at gmail dot com Assigned: bukka (profile)
Status: Closed Package: FPM related
PHP Version: 5.4.35 OS: CentOS 6.6
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: a23878941 at gmail dot com
New email:
PHP Version: OS:

 

 [2014-11-18 01:49 UTC] a23878941 at gmail dot com
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!


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-11-18 02:14 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2014-11-18 02:14 UTC] rasmus@php.net
In your log there should be a line that starts with:

reloading: execvp(...

Could you gist that for us?
 [2014-11-18 02:32 UTC] a23878941 at gmail dot com
NOTICE: pid 9550, fpm_pctl_exec(), line 98: reloading: execvp("/usr/sbin/php-fpm", {"/usr/sbin/php-fpm", "--daemonize"})

Thanks!
 [2014-11-18 18:59 UTC] a23878941 at gmail dot com
-Status: Feedback +Status: Open
 [2014-11-18 18:59 UTC] a23878941 at gmail dot com
Updating status from feedback to open.  Provided feedback in previous comment.
 [2016-10-19 15:56 UTC] emayoral at arsys dot es
Same problem here. Happens also with 5.4 & 5.5 , probably also with 5.6 and 7.0, but we do not have as many pools on those versions.
 [2018-03-30 16:49 UTC] bukka@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: bukka
 [2018-03-30 16:57 UTC] bukka@php.net
Automatic comment on behalf of jacob@ycnrg.org
Revision: http://git.php.net/?p=php-src.git;a=commit;h=77bf9245d22a2a15f0e1654e69c8885ac723dc74
Log: Fix bug #68440: [sapi/fpm] use multiple FPM_SOCKETS env vars to prevent hitting MAX_ARG_STRLEN with a large number of pools
 [2018-03-30 16:57 UTC] bukka@php.net
-Status: Assigned +Status: Closed
 [2018-03-30 16:59 UTC] bukka@php.net
Automatic comment on behalf of jacob@ycnrg.org
Revision: http://git.php.net/?p=php-src.git;a=commit;h=77bf9245d22a2a15f0e1654e69c8885ac723dc74
Log: Fix bug #68440: [sapi/fpm] use multiple FPM_SOCKETS env vars to prevent hitting MAX_ARG_STRLEN with a large number of pools
 [2018-03-30 17:02 UTC] bukka@php.net
Automatic comment on behalf of jacob@ycnrg.org
Revision: http://git.php.net/?p=php-src.git;a=commit;h=77bf9245d22a2a15f0e1654e69c8885ac723dc74
Log: Fix bug #68440: [sapi/fpm] use multiple FPM_SOCKETS env vars to prevent hitting MAX_ARG_STRLEN with a large number of pools
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 11:01:29 2024 UTC