|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68751 listen.allowed_clients is broken
Submitted: 2015-01-05 16:29 UTC Modified: 2015-02-03 08:45 UTC
From: Assigned: remi (profile)
Status: Closed Package: FPM related
PHP Version: 5.5.20 OS: GNU/LInux
Private report: No CVE-ID: None
 [2015-01-05 16:29 UTC]
When multiple address listed, only work of fist call (of each child), then connection from not-first address fails.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-01-05 16:29 UTC]
-Assigned To: +Assigned To: remi
 [2015-01-05 16:36 UTC]
Automatic comment on behalf of remi
Log: Fix bug #68751 listen.allowed_clients is broken
 [2015-01-05 16:36 UTC]
-Status: Assigned +Status: Closed
 [2015-01-06 09:30 UTC] samo dot bracic at gmail dot com
The line 40, where int_addr_t is defined, seems to be redundant after this change.

  40         typedef unsigned int in_addr_t;

Or am I mistaken?
 [2015-01-06 10:21 UTC] igor dot ajdisek at gmail dot com
I can confirm this now works. I no longer see any 'Connection disallowed' errors and all requests succeed.
 [2015-01-06 18:39 UTC] iquito at gmx dot ch
I have a problem with PHP-FPM which seems to be connected to this bug. The detailed version is on , the short of it is:

When multiple addresses are listed in listen.allowed_clients for just one FPM pool config, FPM terminates any further connections from any IP addresses of any pool after one request to any of the pools (as far as I can tell). Only if all pools only have one IP address in listen.allowed_clients FPM seems to work normally again.

This has lead to a complete FPM failure on all of my servers without a hint of where the problem occured, except it is somehow related to FPM, as CLI still worked.

In my opinion, PHP 5.5.20 should not be further distributed as long as this bug is contained in it, as existing configurations are likely to break - multiple IPs in listen.allowed_clients seem a common configuration choice, and mitigating this problem is not straightforward.
 [2015-01-06 18:49 UTC]
@iquito: so please, test the fix.
 [2015-01-06 19:56 UTC] iquito at gmx dot ch
Sorry, but I have never done anything like it - that is why I use debian packages, I have never compiled anything myself and only use well-tested repositories.

I just wanted to describe the error, because I am a "regular user" of PHP who tries to be cautious with upgrading and configuration because of limited resources and in-depth knowledge, but was still stuck with this problem and it had a catastrophic effect on my web servers. That is why I have already tested for hours to somehow "isolate" what happens and make an accurate description, so somebody more experienced and familiar with PHP can find and understand the problem behind it.
 [2015-01-08 18:19 UTC]
@iquito : I'll try to provide (patched 5.5.20 / 5.5.21 if available) packages in the next few days, so that we can provide feedback to @remi.
 [2015-01-19 01:15 UTC]
FYI, a patched 5.5.20 fixes the issue.
 [2015-02-03 08:43 UTC] bananoff at gmail dot com
5.5.20-2.el7.remi bug is still there. Linux 3.10.0-123.13.2.el7.x86_64 #1 SMP Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux; CentOS Linux release 7.0.1406 (Core).
 [2015-02-03 08:45 UTC]
@bananoff so update to 5.5.21
 [2015-02-03 09:18 UTC] bananoff at gmail dot com
@remi tnx, 5.5.21-1.el7.remi works!
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 21 07:01:31 2024 UTC