PHP :: Bug #68751 :: listen.allowed

PHP :: Bug #68751 :: listen.allowed_clients is broken

Bug #68751	listen.allowed_clients is broken
Submitted:	2015-01-05 16:29 UTC	Modified:	2015-02-03 08:45 UTC
From:	remi@php.net	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] remi@php.net

Description:
------------
When multiple address listed, only work of fist call (of each child), then connection from not-first address fails.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2015-01-05 16:29 UTC] remi@php.net

-Assigned To: +Assigned To: remi

[2015-01-05 16:36 UTC] remi@php.net

-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 https://github.com/gplessis/dotdeb-php5/issues/69 , 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] remi@php.net

@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] gui@php.net

@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] gui@php.net

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] remi@php.net

@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!