Pools discovering doesn't work properly when Memcached, Redis or Postgresql is used

[sleptor]

Auto discovering of PHP-FPM pools is a good idea but the current implementation is not cross-platform at least.

The discovery script returns the wrong result on Debian 9 and 10.

For some reason the command lsof -p XXXX returns the result that's unexpected by discovery script.

There are many unix entries and the first of them is not related to php-fpm socket

The discovery script output:

{"data":[{"{#POOLNAME}":"srv"
,"{#POOLSOCKET}":"15068771"
},{"{#POOLNAME}":"www"
,"{#POOLSOCKET}":"15068704"
}]}

How I fixed it? I changed grep expressions to LISTEN\|/run/php. It's not the best fix but it worked for me.

POOL_SOCKET=`$S_LSOF -p $POOL_PID 2>/dev/null | $S_GREP "LISTEN\|/run/php" | $S_HEAD -1 | $S_AWK '{ print $(NF-1)}'`

Another issue is incorrect processing of this php-fpm configuration:

listen = 9000

That means php-fpm daemon listens on all interfaces.

This is the output of the discovery script:

{"data":[{"{#POOLNAME}":"srv"
,"{#POOLSOCKET}":"*:9000"
},{"{#POOLNAME}":"www"
,"{#POOLSOCKET}":"/run/php/php-fpm.sock"
}]}

The status script will not be able to connect to *:9000

How I fixed this issue? I replaced * with localhost

echo -n "${POOL_SOCKET/\*/localhost}" | $S_JQ -aR .

Also, I would remove JQ dependancy. Why do we need it? To build trivial JSON? I guess lesser dependencies is better :)

[rvalitov]

Thank you very much for your information and solutions. I personally use Debian 9 and 10, too, but I didn't face the first problem. I will check your information thoroughly. May be the reason is that I always use PHP repositories of Sury that provides all versions of PHP for different versions of Debian.

Can you please specify what version of PHP do you use and how it was installed (using native PHP package of Debian)?

Thank you for the second problem reported. I didn't think that listen on all interfaces configuration:)

Regarding the jq, yes we need it just to build JSON. It can safely escape all characters, including Unicode. Alternatively we could use json_encode of PHP CLI. However, PHP CLI is also an extra dependency and is not obligatory present even if PHP FPM is installed. I don't think it's a good idea to try to write custom JSON generator in bash. If you have any good approach here, please, let me know.

[rvalitov]

@sleptor Can you please also give a full output for this line in your screenshot:

php-fpm7. 1203 www-data 8u IPv4 15070917 0t0 TCP localhost.localdomain:41610->localhost.

Is it some kind of redirect?

[sleptor]

My examples are based on the latest PHP7.3 installed from Sury repo.

This is full output (lsof -p 6086 | tail -n 4)

php-fpm7. 6086 www-data    6u  unix 0x0000000086ff969f      0t0 872779065 type=STREAM
php-fpm7. 6086 www-data    9u  unix 0x000000005027df81      0t0 872774400 type=STREAM
php-fpm7. 6086 www-data   11u  IPv6              21771      0t0       TCP *:9000 (LISTEN)
php-fpm7. 6086 www-data   12u  IPv4          872854699      0t0       TCP localhost.localdomain:23054->localhost.localdomain:postgresql (ESTABLISHED)

It seems I realized what's "wrong". The fact is my web-application uses several external services such as Memcached, Redis, Postgresql. The app connects to Memcached and Redis using unix sockets, to PostgreSQL using TCP. You can see these connections in LSOF output.

So LSOF returns any sort of unix socket.. we need somehow distinguish php-fpm socket from other possible sockets.

[rvalitov]

@sleptor thank you very much for the details. You are absolutely right about the cause of this problem. I created a new PR #13 to fix all these problems. I made some tests on my machine and it works fine. Please, download the new discovery script from that PR and test if it works on your computer and if it fixes all the problems. The README is also updated and now has info about the debug mode of the discovery script.

[rvalitov]

Closed by #13