Bug #80739 [NEW]: PHP-FPM status page shows listen queue 0

From: Date: Fri, 12 Feb 2021 15:21:52 +0000
Subject: Bug #80739 [NEW]: PHP-FPM status page shows listen queue 0
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-232093@lists.php.net to get a copy of this message
From: micha at dietpi dot com Operating system: Debian Bullseye PHP version: 8.0.2 Package: FPM related Bug Type: Bug Bug description:PHP-FPM status page shows listen queue 0 Description: ------------ I enabled the PHP-FPM status page and configured a handler in Apache2: ``` <Location /status> SetHandler "proxy:unix:/run/php/php8.0-fpm.sock|fcgi://localhost/status" </Location> ``` This is the result: ``` pool: www process manager: static start time: 28/Jan/2021:15:53:44 +0100 start since: 1147547 accepted conn: 1054191 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 11 active processes: 1 total processes: 12 max active processes: 12 max children reached: 0 slow requests: 0 ``` As can be seen, while all running processes have been used concurrently (this is the case after a few hours already, so not a very rare event), the listen queue stays at zero. Especially the listen queue len stays at zero, even that listen.backlog = 1024 is applied in the pool configuration and as well system-wide a sufficient backlog is permitted: ``` net.core.somaxconn = 2048 net.ipv4.tcp_max_syn_backlog = 1024 ``` This is on PHP8.0.2, but it was the same before on PHP8.0.1 and PHP7.4. Steps to reproduce the behavior: 1. Install Debian Bullseye 2. Install Apache2 and PHP-FPM 3. Enable the PHP-FPM status page and the related handler in Apache2 4. Cause more concurrent requests than pm.max_children 5. Watch PHP-FPM status page to show listen queue len and `max listen queue` being zero. Probably related bug report: https://bugs.php.net/bug.php?id=76323 Expected result: ---------------- I would expect that listen queue len matches listen.backlog and that I do see a non-zero value at max listen queue, when the process limit is hit regularly. But probably in this setup it is handled differently? At least connections are not dropped from what I can say, no related error messages appear in either PHP or Apache2 logs, so in fact requests are queried somewhere. Actual result: -------------- listen queue: 0 max listen queue: 0 listen queue len: 0 -- Edit bug report at https://bugs.php.net/bug.php?id=80739&edit=1 -- Fix committed: https://bugs.php.net/fix.php?id=80739&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=80739&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=80739&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=80739&r=needscript Try newer version: https://bugs.php.net/fix.php?id=80739&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=80739&r=support Expected behavior: https://bugs.php.net/fix.php?id=80739&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=80739&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=80739&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=80739&r=globals PHP version support discontinued: https://bugs.php.net/fix.php?id=80739&r=phptooold Daylight Savings: https://bugs.php.net/fix.php?id=80739&r=dst IIS Stability: https://bugs.php.net/fix.php?id=80739&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=80739&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=80739&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=80739&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=80739&r=mysqlcfg

« previous php.bugs (#232093) next »