-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP8.1.3. opcache bug with monolog/monolog #8164
Comments
Also: With PHP7.4 and same opcache settings the same workflow & code is working |
Is a file cache involved? |
All file_cache settings are on default, so should be turned off. ; ...
;opcache.file_cache=
; Enables or disables opcode caching in shared memory.
;opcache.file_cache_only=0
; Enables or disables checksum validation when script loaded from file cache.
;opcache.file_cache_consistency_checks=1
; Implies opcache.file_cache_only=1 for a certain process that failed to
; reattach to the shared memory (for Windows only). Explicitly enabled file
; cache is required.
;opcache.file_cache_fallback=1
; ... |
Thanks for the further info! Did you check the return value of |
Same problem here, no file cache, will check with log and verbosity. |
Here are some logs with grep for the file in question:
After manual reset (when it works again) this gets added:
|
Thanks! First, it is important to understand that when Since in this case the issue apparently happens as of PHP 8.1.0, it might be related to the inheritance cache (introduced with commit 4b79dba). |
Thanks for the link explaining a bit about the opcache! Is this something that's likely to be fixed in a future bugfix release, or do we need to invest some time and change our release process in the long run? |
We are facing this exact issue on one of our servers running PHP 8.0.13. And in our case this error occurs when running a Symfony (v5.4) Console command for which the OpCache is disabled ( Using the "hotfix" works for us now but it's not a satisfying solution ofc. |
@R4c00n, does that issue occur for you with OPcache disabled? If so, we we're probably looking at the wrong places; otherwise, @felixwatzka's issue is something different. |
I did a quick test and it seems like everything is working for us in CLI without opcache. php -a
php > var_dump(opcache_get_status());
bool(false)
php > require_once __DIR__ . '/vendor/autoload.php';
php > $logger = new \Monolog\Logger('debug', [new \Monolog\Handler\StreamHandler('php://output', \Monolog\Logger::DEBUG, true, null, true)]);
php > $logger->addRecord(\Monolog\Logger::DEBUG, 'test');
[2022-03-04T08:40:17.450865+01:00] debug.DEBUG: test [] [] |
apache2handler
apache2handler |
Zend OPcache
Zend OPcache |
Environment
|
@unix-world, PHP 7.4 is no longer actively supported, and as such is irrelevant here. |
It looks like a bug, so it should be fixed; the problem is that it's hard to find the root cause without a somewhat reliable reproduce script. |
Yes, I know, and I agree. I put in this discussion the PHP 7.4 only for some particular reasons:
Does it make sense ? |
Stepping in here since we're seeing this same message in excess in production. I'll try to provide some insights which might (or mightn't) help getting to the source of the issue. It's going to be a bit of lengthy post though. For clarity I'll focus on We're running several Laravel 8.8x applications in Kubernetes which were recently upgraded from php 8.0 to php 8.1.4. The origin of the needs for logging is known, the 'missing' classes however, is not. Whenever that happens, the exception handling of Laravel is triggered, which also uses the Anyway, the request handling will crash causing the Kubernetes probes to fail. During this time, request from legitimate traffic will fail for the same reason. After a while, Kubernetes will kill the unhealthy pods (ending the infinite loop), start new pods and the problem is gone (until it happens again). My colleague managed to catch one of the failures in the act and shot these screenshots of the failing pods running in production: Deprecation notices which are also logged using the logging, causing the same class not found loop error. Error handlers are registered in https://github.com/laravel/framework/blob/v8.83.9/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php#L45 Stack trace through Github links when
And we're back at square one. The Stack trace through Github links when
And we're back at square one. The Locally reproduced (sort of) But it gets even weirder, since we're talking about an infinite loop due a class not found exception I expected to see the stack-trace from the production screenshots. However, what I got was the moment the When stepping into the Apparently requests to unrelated webpages (on the same site) loaded the This caused me to reload the php service via brew to check if that would fix the issue. And sure enough, I haven't been able to reproduce the issue locally anymore despite thousands of requests (as I'm writing this message) and artisan commands both with and without My opcache settings are the same as mentioned by SCIF in #8358 (comment) => opcache ini
This is pretty much as far as I can get. It's hard to reproduce and even harder to pinpoint why this is happening. But from the looks of it, it all points to php's opcache :| Really hoping more information regarding this issue and possible solutions will come to light. Perhaps someone can take a look at the diff between php 8.0 and php 8.1.x regarding opcache? Although I can read a bit of Some other sources which describe the same issue in one form, or another:
|
Thanks a lot for this very detailed analysis. With this new information I believe that this could be related to #8063. I will look at this tomorrow. |
Cool thanks! 🙃 Looking at the description of dd86987 stating |
Should be fixed by #8297 |
@R4c00n and others, could you please check this? Either build from source, or wait for PHP 8.1.6RC1, which is supposed to be released on April, 28th. |
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you. |
Sorry for not getting back here. I removed some logging on our side 3 weeks ago. Since then, the error has not occurred. (this is not really a fix for the actual issue of course) I'll re-enable the logging and deploy some applications in production with a PHP 8.1.6RC1 build. Due to the volatility of the bug, the absence of the error might or might not indicate the issue is solved 🤷♂️ -- |
@Levivb glad to hear RC1 has been working for you so far 👍 @cmb69 I'm ready to update as I've been impacted by this too, but I don't see any reference to this bug in the release notes for 8.1.6? Did it make in to today's release, or should I hold off a bit longer? Thanks 🙏🏻 |
Commit is in the PHP-8.1.6 branch so I assume the release notes are not complete: |
I confirm it's in 8.1.6 👍 (I updated the NEWS file too late to appear in the release notes) |
Great, thanks for your work @arnaud-lb ! 👍 Eagerly waiting for stable docker image 8.1.6 in https://hub.docker.com/_/php?tab=tags&page=1&name=8.1.6 :) |
Description
Using
monolog/monolog
on PHP8.1.3 results in some very weird problems with the classvendor/monolog/monolog/src/Monolog/DateTimeImmutable.php
not being found.There's also already a bugreport in monolog Seldaek/monolog#1626, but it looks like this is an opcache bug.
Our deployment process looks like this:
After that, we get the
PHP message: PHP Fatal error: Uncaught Error: Class "Monolog\DateTimeImmutable" not found in ...
error.Resetting opcache a second time fixes the bug and everything is fine until the next deployment.
PHP Version
PHP 8.1.3
Operating System
Debian
The text was updated successfully, but these errors were encountered: