Support » Localhost Installs » WordPress upgrades then 503 errors until have to reboot

  • Our server has dozens of separate WordPress installations for individual sites. When a site owner upgrades their WordPress, within a minute or less afterwards, any site using PHP gets a 503 “Service Unavailable” message in their browser. The only solution we have found is to reboot. We have tried stopping PHP-FPM, then starting back up after 15 seconds or so. But that does not help. Any idea what could be rendering PHP-FPM non-functional after a WordPress upgrade? Enough so to require a reboot to fix?

    Thanks

Viewing 9 replies - 1 through 9 (of 9 total)
  • Moderator Jose Castaneda

    (@jcastaneda)

    THEME COFFEE MONKEY

    Hi there,

    Have you looked at what the error logs say?

    This seems to be the first error entry tied to problems ….

    “The timeout specified has expired: [client xxx.xxx.xxx.xxx:xxxxx] AH01075: Error dispatching request to :, referer: https://somesite.com/wp-admin/update-core.php?action=do-core-upgrade

    Then a bunch of this type …

    [Mon Apr 01 14:26:45.998971 2019] [proxy_fcgi:error] [pid 26422:tid 139964645857024] (70007)The timeout specified has expired: [client xxx.xxx.xxx.xxx:63031] AH01075: Error dispatching request to :, referer: https://somesite.com/sub1/sub2/

    That error can be caused by Apache timing out and terminating the request. This is a distinct possibility during a WP core update. If that’s the case, you’ll probably need to increase the timeout setting in Apache.

    Otherwise, you should check the PHP-FPM error log, which is usually in /var/log but might also be found in /usr/local/var/log.

    We currently use the defaults for timeouts and execution time for all the components involved.

    When you say “This is a distinct possibility during a WP core update.”

    What timeouts do you use in Apache and fastcgi for PHP-FPM and also things like max_execution_time in PHP?

    Here’s some timeout settings from my httpd.conf file:

    KeepAliveTimeout 4
    GracefulShutdownTimeout 5
    Timeout 30
    ProxyTimeout 120

    My PHP-FPM global settings are all the defaults, except for the location of the pid and log files. I do not set request_terminate_timeout in any FPM pool. I use max_execution_time = 120 in php.ini.

    Note that if a PHP script is waiting (and waiting…) for a curl request to complete, Apache counts that time towards its proxy timeout setting, but PHP does not. And if Apache kills the request due to reaching its timeout setting, the exact error message you provided will be added to the Apache error log.

    Thank you for your assistance. It is appreciated.

    Regarding “Apache counts that time towards its proxy timeout setting, but PHP does not. And if Apache kills the request due to reaching its timeout setting” it seems just increasing ProxyTimeout could have an impact.

    I don’t think I mentioned that sometimes users can upgrade their site ok with no problems. Sometimes we get the above error. I have since learned that some users have quite a few installations of WordPress and may be trying to do a bunch of upgrades at once on occasion.

    Those folks seem to have caused this problem at least 50% of times it has occurred.

    We have …

    KeepAliveTimeout 1
    TimeOut 60
    ProxyTimeout 60

    max_execution_time 30

    So if I understand what you are saying …

    PHP does not count waiting on curl to respond against the “max_execution_time”

    However, it does count against the Apache ProxyTimeOut

    So … PHP-FPM processes keep running, but Apache disconnects from the PHP process if it reaches 60 seconds in our case.

    1) I do not understand why when this is happening that the pm.max_children of PHP-FPM is always reached and none of the php-fpm processes seem to get released

    2) and none of the php-fpm processes seem to terminate get freed to be used by other connections

    THat is correct…Apache will terminate the request when it time exceeds ProxyTimeout. And since PHP-FPM is a system service, the PHP script will keep running until it completes or until max_execution_time is reached.

    What that creates is a message in the Apache error log, and a PHP process that is still running in the background. If enough of these background processes are running, you will eventually exceed pm_max_children, and PHP-FPM will crash. This would be a much larger issue with pm=ondemand than with the other managers.

    Issues with PHP-FPM releasing child processes and FPM pool configurations are beyond the scope of this site. I suggest that you look into request_terminate_timeout and determine whether it will be of help to you. (I think it will.) Also consider raising ProxyTimeout.

    We are in process of moving PHP-FPM from “dynamic” to “on demand”, at least for our individual sites pools. Looks like that may be a mistake.

    Unless the new longer ProxyTimeOut and max_execution_time settings prevent that circumstance.

    At this point we have request_terminate_timeout in PHP-FPM set to “0” (off), the default value.

    So you are saying request_terminate_timeout would be better than using PHP-FPM “ondemand” and it’s pm.process_idle_timeout setting..

    So if someone was doing a WordPress core upgrade, and the WordPress PHP upgrade script was waiting on cURL past PHP-FPM pm.process_idle_timeout, and we were using “ondemand” would the PHP script be terminated before the WordPress upgrade could complete?

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘WordPress upgrades then 503 errors until have to reboot’ is closed to new replies.