Bug #54906
closedFatal error: Interface 'Psr\Log\LoggerInterface' not found
Added by Thomas Skierlo almost 11 years ago. Updated about 6 years ago.
100%
Description
TYPO3 6.2.0beta3 (TYPO3.CMS-HEAD-6335a24) - fresh install (no upgrade)
Fatal error: Interface 'Psr\Log\LoggerInterface' not found in /usr/local/share/typo3/TYPO3.CMS-HEAD-6335a24/typo3/sysext/core/Classes/Log/Logger.php on line 36
This message is re-occurring arbitrary, even after (multiple) cleanups of typo3temp/Cache
Files
tt_address_3.0.0-dev_201403132227.zip (182 KB) tt_address_3.0.0-dev_201403132227.zip | Test Extension | Markus Klein, 2014-03-13 23:31 |
Updated by Steffen Müller almost 11 years ago
I can't reproduce this neither with beta3 nor with current master.
The Psr LoggerInterface is located in typo3/contrib/Psr/Log/LoggerInterface.php
and gets included in typo3/sysext/core/ext_autoload.php
So I guess your troubles are caused by the autoloader.
Could you try to update your TYPO3 sources to the latest version using git master branch, go through the install tool upgrade steps, clear all caches in backend then then reproduce the issue again?
Does the error still occur, when you remove all 3rd party (non sysext) extensions?
What OS do you use?
Updated by Steffen Müller almost 11 years ago
- Status changed from New to Needs Feedback
Updated by Thomas Skierlo almost 11 years ago
I'm currently using latest master (TYPO3.CMS-HEAD-6335a24, two days old), and I'm on Ubuntu 12.04LTS, php 5.3.10. Only 1 comm.-extension installed. Gridelements 3.0.0-dev (for TYPO3 6.2.x), plus 3 of my own extensions. Selective disabling doesn't change things. Problem is: It does not happen often (3 times today, on a 12 hour shift).
Updated by Georg Ringer almost 11 years ago
I am getting this if I clear all caches, the process is not finished and I hit e.g. the tceform of a record in BE ...
Updated by Rupert Germann almost 11 years ago
I'm also getting this error in latest master.
It occurs after leaving the Backend open for several hours, but I can't reproduce it by setting the sessionTimeout to a low value.
strange thing ....
Updated by Sven Tappert almost 11 years ago
When setting config value ['BE']['versionNumberInFilename'] = 0 the error disappeared. Of course this is only one of many dependencies.
Updated by Sven Tappert almost 11 years ago
Maybe a solution:
The reason seems to be that the Psr package is an external package (located under typo3/contrib/Psr).
Therefore the classname to filename mapping is taken from typo3/sysext/core/ext_autoload.php
.
But this is only used the first time the classname cache is built (Early Instance Mapping).
In \TYPO3\CMS\Core\Core\ClassLoader::setPackages()
about line 391 the cached information on the classmap for that early instances is deleted:
// Clear the runtime cache for runtime activated packages
$this->runtimeClassLoadingInformationCache = array();
This is ok if the class cache is created correctly in "typo3temp/Cache/Data/cache_classes/psr_log_loggerinterface
"
But if for some reason the class cache building is incomplete or the cache is not deleted properly we got a deadlock (e.g. "typo3temp/Cache/Data/cache_classes/psr_log_loggerinterface
" is missing, but "typo3temp/Cache/Code/cache_core/ClassLoader_<KEY>.php
" still exists).
So I commented line 391 in the classloader and this helps. But I cannot say if this will produce unexpected results or is an performance issue.
// HOTFIX - DON'T clear the runtime cache for runtime activated packages
// $this->runtimeClassLoadingInformationCache = array();
Updated by Kasper Ligaard almost 11 years ago
I also see this problem constantly with TYPO3 6.2.0beta4. Like others mention, it seems to be some cache-issue: I only see this error after clearing the cache. After some time the site will become available again; of course only until the next time, when the cache is cleared :-(
Updated by Marcin Sągol almost 11 years ago
I can confirm this issue.
When this one shows up? Only if i clear System Cache and click on some page/sysfolder in tree or change action in main content area.
This error won't show up if - after system cache is cleard - we click first some link in modules menu.
So it seems when some module is loaded, some autoloaders are triggered there and class path loaded.
Updated by Steffen Müller almost 11 years ago
Appears also in frontend.
Steps to reproduce:
- Load page in FE
- Clear the class cache, for example with
rm -rf typo3temp/Cache/Data/cache_classes/
- Reload page
Updated by Steffen Müller almost 11 years ago
- Status changed from Needs Feedback to Accepted
Updated by Markus Klein almost 11 years ago
I added a relation to #55099, which seems to hit the same sandbag.
Updated by Thomas Maroschik almost 11 years ago
This always happens when Code and Data caches aren't cleared together. The class loader caches data in the core code cache and some data in it's own data classes cache.
This can also happen if the classes cache is set up on a "volatile" cache backend like apc where some entries expire (although they shouldn't) and the integrity of the cache is not given anymore.
So please, if you delete caches. Kill the whole typo3temp/Cache folder as one.
Updated by Markus Klein almost 11 years ago
Thomas, please have a look into the other issue. I described there how I was able to produce the error also with clearing the whole directory.
Updated by Sven Tappert almost 11 years ago
Could anyone please verify my "hotfix" mentioned above. For me it reduces errors by incomplete class cash to - let's say - 5% AND - maybe more important - you don't end up in a dead lock! The error vanishes with the next reload of the page. I have not seen any negative side effects so far.
Just to repeat it, I proposed to comment the reset of the class loading cache array in TYPO3\CMS\Core\Core\ClassLoader::setPackages(), just before the return statement.
// $this->runtimeClassLoadingInformationCache = array();
Updated by Sven Tappert over 10 years ago
It seems that the current classloader cache implementation with an individual file for each and every class (containing only the class path) is a nice idea but seems not to be suitable for production.
It's painfully slow when the cache is cleared & recreated and it seams to be quite unreliable in situations when the cache is recreated by one request while it is cleared by another (race condition by simultaneous requests). In my opinion it has to be redesigned as soon as possible.
Updated by Markus Klein over 10 years ago
Sven, I fully agree.
The File Cache Backend is really slow. This is one part, but you can choose to change the cache bakcend as you desire by configuration.
The race condition is a general problem of all caches in TYPO3 CMS. I'm working on a general locking solution, to tackle these problems all for once and ever. (#55294)
Updated by Alexander Opitz over 10 years ago
- Assignee set to Alexander Opitz
The ClassLoader cache does not containing only the class path, it also contains the aliases which need to be added. That is the part that costs us much time.
Over 2400 class aliases on my system to be backward compatible.
Updated by Markus Klein over 10 years ago
Link to the blueprint: http://wiki.typo3.org/Blueprints/LockingForCaches
Updated by Gerrit Code Review over 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Sven Tappert over 10 years ago
Markus Klein wrote:
[...] you can choose to change the cache bakcend as you desire by configuration.
Alexander Opitz wrote:
The ClassLoader cache does not containing only the class path, it also contains the aliases which need to be added. That is the part that costs us much time.
Over 2400 class aliases on my system to be backward compatible.
Markus & Alexander, thank you for your replies. I couldn't find any config value to completely disable the cache_classes creation.
Beyond the scope of locking mechanisms, it should be possible somehow to merge all that information together, using a reasonable number of cache files, maybe just one.
Updated by Gerrit Code Review over 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 10 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 11 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 12 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 13 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 14 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 15 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 16 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 17 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 18 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Gerrit Code Review over 10 years ago
Patch set 19 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28156
Updated by Markus Klein over 10 years ago
- Status changed from Under Review to Accepted
- Priority changed from Should have to Must have
- Target version set to next-patchlevel
The patch actually does not solve this issue.
This issues is based on the problem as mentioned in comment 8, that \Psr is not resolved correctly.
Updated by Markus Klein over 10 years ago
How to reproduce¶
- Install the extension provided
- Install or uninstall any other extension
The extension uses a call to ExtensionManagementUtility::makeCategorizable() in ext_tables.php.
This method uses the Logger and the LoggerInterface, which is not properly loaded at that point, and fails therefore.
Solution¶
As suggested by Sven. Maybe reconsider the clearing of the runtimeClassLoadingInformationCache.
Updated by Gerrit Code Review over 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Gerrit Code Review over 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Gerrit Code Review over 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Gerrit Code Review over 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Gerrit Code Review over 10 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Thomas Maroschik over 10 years ago
I think I found the root cause for this issue. The system cache group has been flushed before ext_tables and ext_localconf have been reloaded. This results in the class loader not finding classes/interfaces that have been registered upon initialization. Please test the latest patchset and give a positive review if it solves your issue.
Updated by Gerrit Code Review over 10 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Gerrit Code Review over 10 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28372
Updated by Markus Klein over 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 6e32f103130a1fb31d2676da6f158053489841e2.
Updated by Kurt Gusbeth over 10 years ago
This bug is not fixed. I get this error message after updating from Typo3 6.1.6 to 6.2.0.
Every page is broken...
Updated by Kurt Gusbeth over 10 years ago
This bug is not totally fixed. I get this error message after updating from Typo3 6.1.6 to 6.2.0.
Every page is broken...
Deleting typo3temp/Cache didn´t helped, but deleting the whole typo3temp content helped!
Updated by Markus Klein over 10 years ago
Hi Kurt, please open a new ticket for your issue. We can sort out things there then. Thank you.
Updated by Kay Strobach almost 10 years ago
in my case clearing the cache AND the opcode cache via installtool solved it totaly!