Bug #54906

Fatal error: Interface 'Psr\Log\LoggerInterface' not found

Added by Thomas Skierlo almost 6 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Must have
Category:
-
Target version:
Start date:
2014-03-12
Due date:
2014-03-12
% Done:

100%

TYPO3 Version:
6.2
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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

tt_address_3.0.0-dev_201403132227.zip - Test Extension (182 KB) Markus Klein, 2014-03-13 23:31


Related issues

Related to TYPO3 Core - Bug #55099: PHP Warnings after clearing configuration cache in BE Closed 2014-01-17
Related to TYPO3 Core - Bug #55029: Class Loader fails if entry in class cache is discarded Closed 2014-01-15
Related to TYPO3 Core - Bug #56909: Tx_Extbase_Utility_Extension not found in 6.2.0-beta6 Closed 2014-03-14
Related to TYPO3 Core - Bug #56978: Cannot update extension in EM Closed 2014-03-17
Duplicated by TYPO3 Core - Bug #56740: Cannot activate EXT:dbal from Extension Manager Closed 2014-03-10
Follows TYPO3 Core - Task #56797: Cleanup ClassLoader Closed 2014-03-11

Associated revisions

Revision 6e32f103 (diff)
Added by Markus Klein almost 6 years ago

[BUGFIX] Ensure cache clearing is done properly by EM

This fixes problems with access to classes from ext_localconf
files that were discarded from the classes cache at the wrong
time.

Resolves: #54906
Releases: 6.2
Change-Id: Icf650261a5ed72c36d332e3407ababf627968ab2
Reviewed-on: https://review.typo3.org/28372
Reviewed-by: Wouter Wolters
Tested-by: Wouter Wolters
Reviewed-by: Thomas Maroschik
Tested-by: Thomas Maroschik
Reviewed-by: Anja Leichsenring
Tested-by: Anja Leichsenring
Reviewed-by: Ernesto Baschny
Tested-by: Ernesto Baschny

History

#1 Updated by Steffen Müller almost 6 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?

#2 Updated by Steffen Müller almost 6 years ago

  • Status changed from New to Needs Feedback

#3 Updated by Thomas Skierlo almost 6 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).

#4 Updated by Georg Ringer almost 6 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 ...

#5 Updated by Rupert Germann almost 6 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 ....

#6 Updated by Steffen Müller almost 6 years ago

  • Category deleted (Logging)

#7 Updated by Sven Tappert almost 6 years ago

When setting config value ['BE']['versionNumberInFilename'] = 0 the error disappeared. Of course this is only one of many dependencies.

#8 Updated by Sven Tappert almost 6 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();

#9 Updated by Kasper Ligaard almost 6 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 :-(

#10 Updated by Marcin Sągol almost 6 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.

#11 Updated by Steffen Müller almost 6 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

#12 Updated by Steffen Müller almost 6 years ago

  • Status changed from Needs Feedback to Accepted

#13 Updated by Markus Klein almost 6 years ago

I added a relation to #55099, which seems to hit the same sandbag.

#14 Updated by Thomas Maroschik almost 6 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.

#15 Updated by Markus Klein almost 6 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.

#16 Updated by Sven Tappert almost 6 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();

#17 Updated by Sven Tappert almost 6 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.

#18 Updated by Markus Klein almost 6 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)

#19 Updated by Alexander Opitz almost 6 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.

#21 Updated by Gerrit Code Review almost 6 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

#22 Updated by Sven Tappert almost 6 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.

#23 Updated by Gerrit Code Review almost 6 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

#24 Updated by Gerrit Code Review almost 6 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

#25 Updated by Gerrit Code Review almost 6 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

#26 Updated by Gerrit Code Review almost 6 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

#27 Updated by Gerrit Code Review almost 6 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

#28 Updated by Gerrit Code Review almost 6 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

#29 Updated by Gerrit Code Review almost 6 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

#30 Updated by Gerrit Code Review almost 6 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

#31 Updated by Gerrit Code Review almost 6 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

#32 Updated by Gerrit Code Review almost 6 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

#33 Updated by Gerrit Code Review almost 6 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

#34 Updated by Gerrit Code Review almost 6 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

#35 Updated by Gerrit Code Review almost 6 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

#36 Updated by Gerrit Code Review almost 6 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

#37 Updated by Gerrit Code Review almost 6 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

#38 Updated by Gerrit Code Review almost 6 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

#39 Updated by Gerrit Code Review almost 6 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

#40 Updated by Gerrit Code Review almost 6 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

#41 Updated by Markus Klein almost 6 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.

#42 Updated by Markus Klein almost 6 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.

#43 Updated by Gerrit Code Review almost 6 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

#44 Updated by Gerrit Code Review almost 6 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

#45 Updated by Gerrit Code Review almost 6 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

#46 Updated by Gerrit Code Review almost 6 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

#47 Updated by Gerrit Code Review almost 6 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

#48 Updated by Thomas Maroschik almost 6 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.

#49 Updated by Gerrit Code Review almost 6 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

#50 Updated by Gerrit Code Review almost 6 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

#51 Updated by Markus Klein almost 6 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#52 Updated by Kurt Gusbeth over 5 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...

#53 Updated by Kurt Gusbeth over 5 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!

#54 Updated by Markus Klein over 5 years ago

Hi Kurt, please open a new ticket for your issue. We can sort out things there then. Thank you.

#55 Updated by Kay Strobach almost 5 years ago

in my case clearing the cache AND the opcode cache via installtool solved it totaly!

#56 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF