Wordpress WordPress updates cause error 500 until PHP-FPM restart

I have two different VPSs with Vultr. Both are running latest Centminmod with PHP 7.0.11.

This problem has happened for a while. When I update WordPress or a plugin, every site on my server becomes inaccessible and I receive error 500.

The only thing that fixes this is restarting PHP-FPM.

My permissions and ownership are set properly. Resetting them doesn't make the error 500 go away.

I check the site error logs and the FPM error logs, but there's nothing related to the crash.

My CPU, RAM, and storage aren't maxed out.

Simply restarting FPM fixes things. But I'm concerned about the reliability of that, because if stuff is crashing, it's possible that upgrade processes aren't completing.

---

Any ideas?

 

Yes, I forgot to mention that I keep Centminmod updated, too. I update it before each time that I update anything else.

The WordPress were installed either manually or through the Centminmod menu.

Centminmod was originally installed with 123.07, I think. But some of these sites have been with 123.08stable.

Here's the nginx conf for one of the sites:

Code:

# Centmin Mod Getting Started Guide
# must read http://centminmod.com/getstarted.html

# redirect from non-www to www
# uncomment, save file and restart Nginx to enable
# if unsure use return 302 before using return 301
server {
    listen   80;
    server_name podcasterssociety.com www.podcasterssociety.com;
    # return 301 $scheme://www.podcasterssociety.com$request_uri;
    return 301 https://$server_name$request_uri;

  }

server {
    server_name podcasterssociety.com www.podcasterssociety.com;

    # ngx_pagespeed & ngx_pagespeed handler
    #include /usr/local/nginx/conf/pagespeed.conf;
    #include /usr/local/nginx/conf/pagespeedhandler.conf;
    #include /usr/local/nginx/conf/pagespeedstatslog.conf;

    # limit_conn limit_per_ip 16;
    # ssi on;

    access_log /home/nginx/domains/podcasterssociety.com/log/access.log combined buffer=256k flush=60s;
    error_log /home/nginx/domains/podcasterssociety.com/log/error.log;

    root /home/nginx/domains/podcasterssociety.com/public;


    # SSL
    # force https-redirects
    # if ($scheme = http) {
    # }
    listen 443 ssl http2;
    ssl on;
    ssl_certificate /usr/local/nginx/conf/ssl/theaudacitytopodcast.com.crt;
    ssl_certificate_key /usr/local/nginx/conf/ssl/theaudacitytopodcast.com.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#    ssl_prefer_server_ciphers on;
#    ssl_ecdh_curve  secp384r1;
#    ssl_session_cache      shared:SSL:10m;
#    ssl_session_timeout  10m;
#    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!CAMELLIA;
#    add_header Strict-Transport-Security "max-age=0; includeSubdomains";
    # /SSL

      # prevent access to ./directories and files
    location ~ (?:^|/)\. {
        deny all;
    }

    # include /usr/local/nginx/conf/wpsupercache_podcasterssociety.com.conf;

    # location / {
    # # Enables directory listings when index file not found
    # #autoindex on;
    #
    #     try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?q=$uri&$args;
    #
    # }

    location / {

      if (-f $request_filename/index.html){
        rewrite (.*) $1/index.html break;
      }

      if (-f $request_filename/index.php){
        rewrite (.*) $1/index.php;
      }

      if (!-f $request_filename){
        rewrite (.*) /index.php;
      }

      # block common exploits, sql injections etc
      include /usr/local/nginx/conf/block.conf;
    }


#    location ~* /(wp-login\.php) {
#        limit_req zone=xwplogin burst=1 nodelay;
#        #limit_conn xwpconlimit 30;
#    #    auth_basic "Private";
#    #    auth_basic_user_file /home/nginx/domains/podcasterssociety.com/htpasswd_wplogin;
#        include /usr/local/nginx/conf/php-wpsc.conf;
#    }

#    location ~* /(xmlrpc\.php) {
#        limit_req zone=xwplogin burst=2 nodelay;
#        #limit_conn xwpconlimit 30;
#        include /usr/local/nginx/conf/php-wpsc.conf;
#    }

    include /usr/local/nginx/conf/rocket-nginx/rocket-nginx.conf;
    # include /usr/local/nginx/conf/wpsecure_podcasterssociety.com.conf;
 include /usr/local/nginx/conf/wpsecure.conf;
#    include /usr/local/nginx/conf/php-wpsc.conf;
    include /usr/local/nginx/conf/php.conf;
    include /usr/local/nginx/conf/staticfiles.conf;
    include /usr/local/nginx/conf/drop.conf;
    #include /usr/local/nginx/conf/errorpage.conf;
}

 

I did those couple clean-ups and also updated the WP Rocket conf (only WP Rocket stuff in my site conf is the link to their conf). I'm suspecting the lack of updating the WP Rocket conf could have been my problem. But whatever the case, I won't know until another plugin or core update is available.

But now restarting nginx gives me this error:

Code:

nginx: [warn] could not build optimal variables_hash, you should increase either variables_hash_max_size: 1024 or variables_hash_bucket_size: 64; ignoring variables_hash_bucket_size

 

That's not working for me. But this does seem to be only a warning, so I'll ignore it for now. I'll post an update the next time I see a WP update come through.

 

Yeah, I put in that code and removed the later duplicate of one of those. But restarting nginx still gives me the same warning.

Code:

$ grep -Rn 'hash_' /usr/local/nginx/conf/
/usr/local/nginx/conf/nginx.conf:22: map_hash_bucket_size 128;
/usr/local/nginx/conf/nginx.conf:23: map_hash_max_size 4096;
/usr/local/nginx/conf/nginx.conf:24: server_names_hash_bucket_size 128;
/usr/local/nginx/conf/nginx.conf:25: server_names_hash_max_size 2048;
/usr/local/nginx/conf/nginx.conf:26: variables_hash_max_size 1024;
/usr/local/nginx/conf/nginx.conf:100: types_hash_max_size 2048;

 

1.11.4

 

I've updated plugins several times and it seems this original problem is fixed. So it probably was Rocket-Nginx. However, I have yet to see a WordPress core update come through.

 

I should've said it this way.

I have yet to see whether a WordPress core update works properly, as there hasn't been one, yet, since I last had this problem. I'll repost when I have resolution.