Bug #76205 [NEW]: PHP-FPM sporadic crash when running Infinitewp

From: 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

« previous php.bugs (#214688) next »