PHP脚本意外终止、间歇性终止及php-fpm超时日志解读的技术咨询

Hey there, let's walk through your problem step by step—first tackling those intermittent script termination issues, then breaking down that php-fpm log entry you shared.

一、间歇性PHP脚本终止（闲置后/新浏览器登录时）的可能原因 #

From what you described (issues popping up after inactivity or new browser logins, fixing after retrying), here are the most likely culprits:

• Timeout configuration mismatches: Check your php-fpm settings like request_terminate_timeout, or your web server (Nginx/Apache) timeout values. After periods of inactivity, idle connections might get dropped by the server or intermediate layers, and your first login request hits that timeout window. Retrying creates a fresh connection that works.
• Stale session/cache connections: If your app uses session storage (like Redis/Memcached) or external services, idle connections to these might drop after being unused. The first login request tries to use a dead connection, causing a hang that times out—retrying triggers a new connection, fixing the issue.
• Resource contention after idle periods: When the server is idle, it might release resources like database connections. Your first login request has to wait to re-acquire these resources, hitting the timeout threshold. By the time you retry, the resources are already available.
• Firewall/load balancer idle timeouts: Cloud load balancers, firewalls, or proxy services often kill idle connections after a set period. Your first post-inactivity request uses a stale connection that's already been terminated, causing the script to hang. Retrying establishes a new, valid connection.
• WordPress-specific plugin/validation delays: Since this happens on wp-login.php, security plugins, CAPTCHA services, or login validation logic might be the issue. After inactivity, these might need to re-fetch data (like rule updates or CAPTCHA tokens) from external services, leading to a timeout on the first attempt—retrying uses cached data or a fresh fetch that succeeds.

二、php7.4-fpm.log日志解读 #

Let's break down the log lines you provided:

[24-Mar-2024 05:49:47] WARNING: [pool domain] child 2889619, script '/home/domain/public_html/wp-login.php' (request: "POST /wp-login.php") execution timed out (218.590861 sec), terminating
[24-Mar-2024 05:49:47] WARNING: [pool domain] child 2889619 exited on signal 15 (SIGTERM) after 31074.802894 seconds from start

• First line: This tells you that the php-fpm child process 2889619 (part of the domain pool) was handling a POST /wp-login.php request, but the script execution took 218+ seconds—way over the allowed timeout limit. Php-fpm is now terminating this process to free up resources.
• Second line: The child process 2889619 was successfully stopped with the SIGTERM signal (a normal, graceful termination signal, not a crash). This process had been running for ~31074 seconds (about 8.6 hours) before being terminated due to the timeout.

Quick Troubleshooting Tips #

• Check your php-fpm.conf for request_terminate_timeout—the 218-second timeout is likely close to this value. You might need to adjust it temporarily to capture more details, or fix the root cause of the slow execution.
• Enable slowlog in php-fpm (set request_slowlog_timeout to a lower value, like 10 seconds) to log exactly what parts of wp-login.php are taking so long—this will point you to slow database queries, external API calls, or plugin code.
• Verify idle timeout settings for your database, cache services, and any proxy/load balancers—ensure they either match your app's timeout values or that your app handles connection reconnection gracefully.
• For WordPress, try disabling non-essential login-related plugins temporarily to see if the issue goes away, which would narrow down the culprit.

备注：内容来源于stack exchange，提问作者R Z