newrelic-php-agent: Thousands of E_WARNING "Failed to open stream: No such file or directory" after upgrading from 10.17.0.7 to 10.18.0.8
Description
We bumped from 10.17.0.7 to 10.18.0.8 and noticed lots of E_WARNING errors being reported:
include(/var/www/app/var/cache/prod/pools/system/9HGRhXbDyv/N/J/lJlB08wWBKnILB1B6L9w): Failed to open stream: No such file or directory
Steps to Reproduce
I don’t know
Expected Behavior
No warning.
Relevant Logs / Console output
include(/var/www/app/var/cache/prod/pools/system/9HGRhXbDyv/N/J/lJlB08wWBKnILB1B6L9w): Failed to open stream: No such file or directory
in Symfony\Component\Cache\Adapter\PhpFilesAdapter::doFetch called at /var/www/app/vendor/symfony/cache/Traits/AbstractAdapterTrait.php (193)
in Symfony\Component\Cache\Adapter\AbstractAdapter::getItem called at /var/www/app/vendor/doctrine/persistence/src/Persistence/Mapping/AbstractClassMetadataFactory.php (200)
in Doctrine\Persistence\Mapping\AbstractClassMetadataFactory::getMetadataFor called at /var/www/app/vendor/doctrine/orm/src/EntityManager.php (318)
in Doctrine\ORM\EntityManager::getClassMetadata called at /var/www/app/vendor/doctrine/orm/src/UnitOfWork.php (3410)
in Doctrine\ORM\UnitOfWork::getSingleIdentifierValue called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (434)
in Doctrine\ORM\AbstractQuery::processParameterValue called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (479)
in Doctrine\ORM\AbstractQuery::processArrayParameterValue called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (415)
in Doctrine\ORM\AbstractQuery::processParameterValue called at /var/www/app/vendor/doctrine/orm/src/Query.php (458)
in Doctrine\ORM\Query::resolveParameterValue called at /var/www/app/vendor/doctrine/orm/src/Query.php (402)
in Doctrine\ORM\Query::processParameterMappings called at /var/www/app/vendor/doctrine/orm/src/Query.php (318)
in Doctrine\ORM\Query::_doExecute called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (1212)
in Doctrine\ORM\AbstractQuery::executeIgnoreQueryCache called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (1166)
in Doctrine\ORM\AbstractQuery::execute called at /var/www/app/vendor/doctrine/orm/src/AbstractQuery.php (901)
in Doctrine\ORM\AbstractQuery::getResult called at /var/www/app/src/Shared/SomeRepository.php (35)
[truncated]]
in Symfony\Component\HttpKernel\HttpKernel::handleRaw called at /var/www/app/vendor/symfony/http-kernel/HttpKernel.php (76)
Your Environment
Symfony v7.0 PHP 8.3.2 Debian 12
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Reactions: 3
- Comments: 26 (8 by maintainers)
Fixed with 10.19.0.9 release: https://github.com/newrelic/newrelic-php-agent/releases/tag/v10.19.0.9
Thanks for all the feedback in this thread. We are continuing to investigate the issues and usage cases that are detailed here and the more details you provide the more we can work to resolve the problems.
A few notes:
Yes, this is a separate issue with a fix that will go out in the next release
@zsistla I think I was not really clear. Some parts of a framework or library, a temporary error handler is created to catch and suppress expected warnings or errors. I think this happens quite often with caching libraries and specific for file adapters. They will directly try to load a cache file without checking if the file exists (you will save a stat on a filesystem, this will increase performance) but will throw a warning when not exists (this is expected) and will be handled by the temporary custom error handler. We are now flooded by these warnings with this version of the agent.
I agree, but also think it should also take into account things custom error handles suppress. I have
error_reportingset toE_ALLbecause I want to know about errors, but then there are places where I want to suppress errors (e.g. from frameworks). If a framework was hiding errors from NewRelic, there’s probably a good reason to do so because it’s not actually an issue. If there are frameworks that are hiding true issues in the error handler, I think the error handler should be updated to handle it better (e.g. allow error handling to continue after the current handler or have it use the NewRelic API to report the error).So what does that mean, that all NR PHP SDK customers need to manually exclude these errors that are normally not visible?
I believe NR should handle this in the Symfony integration. And not bother users with it.
Sorry for the confusion. This did fix it. Thank you. It looks like the yum update didn’t see the new package on a handful of our servers and those were the ones I was seeing errors from.
Just tried it out and it does indeed fix the problem. Thanks everyone 💪 💙
We’ve downgraded to the 10.17.0.7 agent for now, having handled warnings recorded as errors is quite a nuisance and unwanted behaviour. We would still like to see warnings in our logs, but not when they are expected and handled by the framework.
For Red Hat (yum) based distros you can use the versionlock plugin to lock the agent to 10.17.0.7:
I’m seeing the same issue with the Smarty Template Engine. I don’t want to set
newrelic.error_collector.ignore_errorsto exclude allE_WARNING. I wish there was at least a way to ignore errors if the error originated from a specific file, but I don’t see an option for that. Ideally, the agent would revert back to the old behavior of not reporting errors that other error handlers handled/suppressed.@zsistla in this case the framework tries to suppress the errors / warnings because they are expected and then handled by themselves. How should frameworks do that otherwise? How can we ignore those messages if this is a feature and not a bug?