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

Edit report at https://bugs.php.net/bug.php?id=76205&edit=1 ID: 76205 Comment by: post at minhost dot no Reported by: post at minhost dot no Summary: PHP-FPM sporadic crash when running Infinitewp Status: Open Type: Bug Package: opcache Operating System: CentOS 7.4 PHP Version: 7.1.16 Block user comment: N Private report: N New Comment: I have patched PHP 7.1.16 now. The problem described seems to have been resolved. However, for a few months we have customers running Drupal that get 503 errors sporadic, mostly when running update.php in Drupal, but lately also when doing other changes in Drupal control panel. We are running both opcache in memory, and has second level fallback opcache on disk in a directory for each user. I suspect most of the 503 errors in Drupal is related to opcache on disk. It just does not seems to be stable enough for production servers. However the only reason we run second level fallback opcache on disk, is to avoid users not getting cache after each time apache or php-fpm is reloaded. This happens several times each day, because it must happen whenever a user add a domain og install lets encrypt certificates. Also it happens every night during log rotate. If you could add a ini setting that would allow us to set opcache to not be empty whenever there is a apache og php-fpm reload, then we would no longer need second level fallback opcache on disk. Would it be possible to add a ini setting to set opcache to not be emptied whenever apache or php-fpm is reloaded? So that we could deactivate opcache on disk and only use opcache in memory? Previous Comments: ------------------------------------------------------------------------ [2018-04-11 02:28:18] post at minhost dot no What I mean is that if I click on "View" from the patch at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e I get this file https://github.com/php/php-src/blob/b6a41ad5ba2f853d44e6184375968a86c8167f1e/ext/opcache/zend_persist.c wich has other differences when adding to stable PHP 7.1.16 then the diff at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e Kind of confusing, please confirm I can manually add the patch at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e into the stable PHP 7.1.16 file? ------------------------------------------------------------------------ [2018-04-11 02:07:23] post at minhost dot no Are you sure I can use the patch at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e directly into the stable PHP 7.1.16 file ext/opcache/zend_persist.c? Because if I copy the entire file from the patch and overwrite it, there is other differences then just the commit at the patch. ------------------------------------------------------------------------ [2018-04-10 17:36:55] post at minhost dot no Thanks. After manually applying the patch at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e into ext/opcache/zend_persist.c in PHP 7.1.16 and then recompiling PHP 7.1.16 - would it then be needed or recommended to empty all opcache files in .opcache folders on disk? I hope you wil make sure that the patch will make it into the next PHP 7.1.17? I must also comment that there has been to many problems with running opcache on disk as fallback cache, and I feel I am the only one doing it, and therefor bugs might not be reported by anyone but me. I really consider to stop using opcache on disk as second level fallback cache to avoid any more problems. But I would like to keep it, if it would just not be so many bugs popping up from time to time. ------------------------------------------------------------------------ [2018-04-10 17:20:13] nikic@php.net It's unlikely that the mentioned bug is related (because it affects optimization, not caching). However, PHP 7.1.16 contains a number of changes in the caching logic, including https://github.com/php/php-src/commit/50949c9332b897c6848839357ad97223a0e1dd38, which introduced an issue subsequently fixed in https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e. Unfortunately, it looks like this commit missed the PHP 7.1.16 cut. You might want to try applying the patch from the second commit and see if it resolves the issue. ------------------------------------------------------------------------ [2018-04-10 17:02:35] post at minhost dot no 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 this bug report at https://bugs.php.net/bug.php?id=76205&edit=1