Bug #76205 [NEW]: PHP-FPM sporadic crash when running Infinitewp
| From: | post at minhost dot no | Date: | Tue, 10 Apr 2018 17:02:39 +0000 |
| Subject: | Bug #76205 [NEW]: PHP-FPM sporadic crash when running Infinitewp | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-214688@lists.php.net to get a copy of this message | ||
From: post at minhost dot no
Operating system: CentOS 7.4
PHP version: 7.1.16
Package: opcache
Bug Type: Bug
Bug description:PHP-FPM sporadic crash when running Infinitewp
Description:
------------
After upgrading our shared hosting servers from PHP 7.1.15 to PHP
7.1.16, some users running Infinitewp to update their WordPress sites
experience that when they do "Reload data" in Infinitewp, then some of
their WordPress sites go down with this error:
"HTTP Error 503: Service Unavailable - The request was not completed.
The server is temporarily overloading or down."
And PHP-FPM is down on those sites. This never happen in previous PHP
7.1.15
To get the sites up and running again, I need to reload php-fpm71
In Apache error log we get errors like this:
[Tue Apr 10 17:12:06.695643 2018] [proxy_fcgi:error] [pid 31674:tid
139648101607168] [client 194.242.11.18:56034] AH01067: Failed to read
FastCGI header, referer:
https://domain.tld/?no_cache_KFoZ4ai5=1523373126
[Tue Apr 10 17:12:06.695691 2018] [proxy_fcgi:error] [pid 31674:tid
139648101607168] (104)Connection reset by peer: [client
194.242.11.18:56034] AH01075: Error dispatching request to : , referer:
https://domain.tld/?no_cache_KFoZ4ai5=1523373126
In /usr/local/php71/var/log/php-fpm.log I get this:
[10-Apr-2018 17:12:06] WARNING: [pool sommerfr] child 24746 exited on
signal 11 (SIGSEGV) after 8409.340823 seconds from start
[10-Apr-2018 17:12:06] NOTICE: [pool sommerfr] child 17221 started
Please note that I am running both normal opcache in memory, and also
has opcache on disk as a fallback cache (to be used whenever opcache get
empty during restarts). Here is my ini settings:
opcache.memory_consumption=32768
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=1000000
opcache.revalidate_freq=0
opcache.validate_timestamps=1
opcache.fast_shutdown=1
opcache.enable_cli=0
opcache.validate_permission=1
opcache.validate_root=1
opcache.use_cwd=1
opcache.revalidate_path=1
opcache.enable_file_override=1
opcache.file_cache_only=0
opcache.max_wasted_percentage=10
One thing I suspect could play a role, is that all the sites that went
down after running "Reload data" in Infinitewp, had one thing in common,
that is: Nobody had visited WordPress dashboard on those sites, so at:
/home/USER/.opcache/0d01841927accbb2865ecf61ea43a8ce/home/USER/domains/DOMAIN.TLD/public_html/wp/wp-admin
There was only 1 directory and 2 files, when I manually visited
WordPress dashboard, several more files where added in opcache on that
path. So maybe the bug only happen if disk based opcache have not yet
cached all needed files before running "Reload data" in Infinitewp?
I can not say for sure, as the problem has been sporadic when running
Infinitewp after upgrading to PHP 7.1.16
Further I have been looking at the changelog for PHP 7.1.16 and PHP
7.2.4, in PHP 7.1.6 changelog at
http://www.php.net/ChangeLog-7.php#7.1.16
there is this:
Opcache:
Fixed bug #76074 (opcache corrupts variable in for-loop).
However when looking at changelog for PHP 7.2.4, bug #76074 is not
mentioned at all! I find that strange because at the page for bug #76074
it says "PHP Version: 7.2.3"
So why was fix for bug #76074 not added in PHP 7.2.4? And was it a
mistake that it was added to 7.1.16?
Beacause that is the only bug fix for Opcache in PHP 7.1.16, I think it
could be related to our users problems in PHP 7.2.16 as described above.
--
Edit bug report at https://bugs.php.net/bug.php?id=76205&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=76205&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=76205&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=76205&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=76205&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=76205&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=76205&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=76205&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=76205&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=76205&r=support
Expected behavior: https://bugs.php.net/fix.php?id=76205&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=76205&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=76205&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=76205&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=76205&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=76205&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=76205&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=76205&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=76205&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=76205&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=76205&r=mysqlcfg