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: Update: The patch did not solve the problem after all. It happened again for a customer running "Reload data" in IWP, PHP-FPM on 3 of his sites crashed and displayed a 503 error. This time I reset OPcache with a PHP file containing this, and the sites started working again: <?php opcache_reset(); ?> So whenever this happen, I must either reload PHP-FPM, or run the above PHP code. So the patch at https://github.com/php/php-src/commit/b6a41ad5ba2f853d44e6184375968a86c8167f1e did not work! Ever since PHP 7.1.11 there has been nothing but problems with bugs relateded to OPcache poping up all the time. And you continue to create new bugs in OPcache every time you release a new PHP version, and the new bugs is not fixed. Do you ever do any testing of your code changes at all? No, it does not seem like you do any testing at all! Previous Comments: ------------------------------------------------------------------------ [2018-04-13 11:58:49] post at minhost dot no 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? ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76205 -- Edit this bug report at https://bugs.php.net/bug.php?id=76205&edit=1