Bug #67366
closed
PHP Errors after clearing cache in BE
Added by Alexander Ließmann almost 9 years ago. Updated about 3 years ago.
0%
Description
Since we updated some of our customer sites to TYPO3 6.2, we saw some PHP errors in FE like this one:
Fatal error: Class 'tx_igldapssoauth_config' not found in /var/www/typo3conf/ext/ig_ldap_sso_auth/Configuration/TCA/Config.php on line 172
or this:
Fatal error: Class 'tx_realurl_apiwrapper' not found in /var/www/typo3conf/ext/realurl/class.tx_realurl.php on line 177
There were some other errors with other class names. The problem seems to target a random class. It appears in TYPO3 BE and FE after clearing the cache. But not always, and this makes it strange for me.
I was able to provoke the behavior with something i found in the comments of a existing bug report:- Open page in FE
- rm -rf typo3temp/Cache/Data/cache_classes/
- Reload page in FE
If i have a look in typo3temp/Cache/Data/cache_classes/ now, there are only few files in it. The class, which is named by the error message, is listed as a 0 Byte file.
I found Bug #55099 and i thought this could be related.
Files
| monitor_error_log.sh (514 Bytes) monitor_error_log.sh | Tobias Schaefer, 2015-08-06 16:27 |
Updated by Markus Klein almost 9 years ago
Now that I read this here, I dimly remember having seen such an issue on a 6.2 instance as well. I thought of a realurl bug and moved to the version of helhum.
I'll install the original realurl again and will re-test.
Updated by Markus Klein almost 9 years ago
- Category set to Caching
- Status changed from New to Accepted
- Assignee set to Markus Klein
- Target version set to 6.2.13
- Sprint Focus set to Stabilization Sprint
Updated by Markus Klein almost 9 years ago
- Status changed from Accepted to Needs Feedback
- Assignee deleted (
Markus Klein) - Target version deleted (
6.2.13) - Sprint Focus deleted (
Stabilization Sprint)
Even though I could reproduce this on one of our sites, I'm failing to reproduce it again after having played around.
I did:- upgrade realurl from 1.12.8 to 1.13.3 via extension manager
- clear system caches
- clear general caches
- hard-remove typo3temp/Cache/*
the error in FE persisted:
Fatal error: Class 'tx_realurl_apiwrapper' not found in ....typo3conf/ext/realurl/class.tx_realurl.php on line 177
I made an intermediate upgrade to 6.2.13-dev and cleared typo3temp/Cache/* again and all of a sudden it worked.
I tried to reproduce by downgrading to 6.2.12 again, resetting realurl back to 1.12.8, clear all caches and re-did the update to 1.13.3 => still working
I did not clear the OPcode cache (which I never had to), so maybe this is related to this cache somehow.
(I tested on PHP 5.5)
Are you using the opcode cache of PHP? If so please try clearing it manually via Install Tool.
Updated by Alexander Ließmann almost 9 years ago
Currently we do not use an OPcode cache, so there should not be the Problem. Our TYPO3 Version is 6.2.12 and the realurl version is 1.13.3.
I found out how to reproduce the two errors mentioned in my posting above. We use the extension igldapssoauth for backend login. So this error is raised in the following cases:
- Backend login attempt if typo3temp/Cache/Data/cache_classes is empty
- Backend login refresh with Ajax if typo3temp/Cache/Data/cache_classes is empty
- Call on "typo3/cli_dispatch.phpsh extbase something" if typo3temp/Cache/Data/cache_classes is empty
The realurl error is shown on a FE call only.
I have seen a third error mentioning a classname of one of our own extensions, but until now i do not know how to reproduce this one. It is used in a long running process called by crontab. Perhaps it occurs when the process is running and the folder typo3temp/Cache/Data/cache_classes is cleared in the meanwhile...
Updated by Markus Klein almost 9 years ago
I was told this issue should be resolved in 6.2.13, which will be released in the next few hours. Please test again with .13 then.
This must have been some issue in the class loader as I could verify the empty cache files. As I said, I'm not able to reproduce again and I'm sure I had no concurrent requests running.
Updated by Kerstin Gerull almost 9 years ago
Hi,
I am having nearly the same problem. I am not completely sure if it is exactly the same.
When you have too much traffic on your page the cache is not cleared completely before new cache entries arrive.
That is why I get the following error:
"PHP Fatal error: Class 'Tx_Solr_PluginCommand' not found in <path>/typo3temp/Cache/Code/cache_core/ext_localconf_97bba9aa9ddf78aa54d1ba36d6ec429832fc4c76.php"
But this is just an example.
Like Alexander Ließmann initially stated, this error message seams to be random, because the error can occure on every cached class. And if you test that at midnight (with nearly no traffic) everything works fine.
This is the test I can reproduce the error.
1. Use wget to read the hole page recursivly (to make traffic)
- I did this on our testing environment, because the live page has enough traffic to allways have the error
2. Clear the Cache in the Install Tool (TYPO3 6.2.9 and 6.2.13)
- And you get a white page with a 'random' error message.
Could someone else reproduce this problem on TYPO3 Version 6.2.13?
Greetings Kerstin
Updated by Markus Klein almost 9 years ago
- Status changed from Needs Feedback to New
Reading your text brings another idea to my mind. I guess the caches are not locked before being cleared, therefore those concurrency issues occur, which are especially bad for the class loader cache.
Will be hard to fix that, but lets see.
Updated by Patrick Schriner almost 9 years ago
I'm having this issue as well. I'm getting 0 KB (empty) cache files in cache_classes on those classes it cannot find.
I don't know whether this is symptomatic or the cause.
Updated by Alexander Opitz almost 9 years ago
Thats the cached result, that it didn't find the classes.
Updated by Markus Klein almost 9 years ago
Please always specify the exact TYPO3 version you are using. Thanks.
Updated by Alexander Wende over 8 years ago
Maybe this Issue is related to https://forge.typo3.org/issues/54984 ?
Updated by Tobias Schaefer over 8 years ago
- File monitor_error_log.sh monitor_error_log.sh added
Some of my TYPO3 sites (6.2.14) are suffering from this bug too. And after it happend this morning again, I thought about a workaround. Of course it would be great if the problem doesn't occur anymore at all, but meanwhile I worked out a workaround. It's a shell script that monitors apaches error-log and clears typo3temp/Cache if the string "PHP Fatal error: Class" is found in the error-log. It is saving the position in error-log where it was already checked, so it only clears typo3temp/Cache if there're new entries in the error-log. The script runs every minute via cron. Of course this is only possible if you're using Unix, Linux or Mac OS X.
The script monitor_error_log.sh is attached. The variables at the beginning (logfile, searchstr, cachefile, typo3path) have to be adapted to your environment. Just copy it to /root/cron/ and add the following to the crontab (crontab -e):
* * * * * /root/cron/monitor_error_log.sh >/dev/null 2>&1
Updated by Markus Klein over 8 years ago
- Category changed from Caching to Backend API
- Status changed from New to Accepted
- Target version set to 6.2.15
- Sprint Focus set to Stabilization Sprint
This occurred to me as well some time ago. This is not a caching issue, but seems to be a defect in discovering classes properly. Helmut is informed, but we fail to reproduce this reliably.
A related ticket maybe is #67246
Updated by Ralf Merz over 8 years ago
Hi guys,
I just can confirm on instances after upgrading from 6.2.12 to 6.2.14, I get an error after "clear all caches" in install tool immediately after clicking the button like:
PHP Warning: require_once(.../htdocs/typo3temp/Cache/Code/cache_core/ClassLoader_75fde3487a164478ad1b5ce95564b364.php): failed to open stream: No such file or directory in .../typo3_src/typo3/sysext/core/Classes/Cache/Backend/SimpleFileBackend.php on line 364
We have OpCache enabled. On my local machine I cannot reproduce this with or without OpCache enabled.
Reloading the backend gives a white page for about 7 seconds, then the cache is up again and the system works again as expected.
Maybe this helps.
Regards
merzilla
Updated by Alexander Opitz over 8 years ago
@Ralf Merz
This looks like another issue. You may find "Could not acquire look" error messages in your log files.
Updated by Gilles Fouet over 8 years ago
We got this error:
Fatal error: Class 'tx_realurl_apiwrapper' not found in /var/www/typo3conf/ext/realurl/class.tx_realurl.php on line 177
"typo3temp/Cache/Data/cache_classes/tx_realurl_apiwrapper" was empty when calling a frontend page with empty caches.
By activating "[SYS][displayErrors]" we got the fatal error displayed (with missing image information) instead of a blank page.
It was due to missing images in a call of <f:images>.
We also got the "typo3temp/Cache/Data/cache_classes/" with empty files when calling page from backend in production environment.
The patch in #67246 resolved this issue.
Updated by Markus Klein over 8 years ago
- Status changed from Accepted to Closed
- Target version deleted (
6.2.15)
Since it is reported that #67246 solves the issue, I close this issue. We fail to reproduce this reliably.
Updated by Michal Cygankiewicz almost 5 years ago
Seems like same problem still exists in TYPO3 8.7.25. We are getting strange errors for some requests just right after clearing caches in backend - but only if there is some traffic on the website (multiple users online) - then some of the users get error 500 and others not - this happens in about up to first 30 seconds after clearing cache. However since our website is quite high traffic that means many users get error 500 during that time.
Example error is:
"Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1166546734: Package "realurl" is not available. Please check if the package exists and that the package key is correct (package keys are case sensitive). | TYPO3\CMS\Core\Package\Exception\UnknownPackageException thrown in file .......vendor/typo3/cms/typo3/sysext/core/Classes/Package/PackageManager.php in line 500. Requested URL: ......................."
Updated by Markus Klein almost 5 years ago
- Status changed from Closed to New
- Sprint Focus deleted (
Stabilization Sprint)
We need to find a way how this can be reproduced locally. With pen-testing or whatever.
Updated by Michal Cygankiewicz almost 5 years ago
I was able to reproduce that locally too. When I do that manually on local/dev etc I am just opening several (10 is usually enough) subpages of my website in another browser. Then I am clearing cache and then after that I am refreshing those pages as fast as possible. Usually few of them return error 500 while some others return 200 OK.
So it is matter of sending some requests to the page right after clearing cache.
Updated by Markus Klein almost 5 years ago
Can you reproduce this on a plain new (empty) TYPO3 instance, or does it require some/certain extensions to be installed?
Can you maybe provide the list of extensions you have activated?
Updated by Michal Cygankiewicz almost 5 years ago
I've just made clean installation of TYPO3 8.7.25 and installed introduction package so that I have some frontend displayed. And I am able to reproduce that problem.
In order to reproduce I need to set memory_limit on my server as low as possible - however it should be high enough so that server is not returning "PHP Fatal error: Allowed memory size of ..... bytes exhausted (tried to allocate ....bytes)". In my case if I set 16M memory_limit I am getting that error but if I set 32M memory_limit then I am not getting that error anymore but instead TYPO3 error. So I am proceeding with 32M memory limit to be able to reproduce that error.
Then I am proceeding as described in previous comment already. Opening 5-10 subpages, clearing caches in backend and then refreshing those pages (incognito) as fast as possible. In that case I am getting errors like (however not always but only sometimes):
Core: Exception handler (WEB): Uncaught TYPO3 Exception: syntax error, unexpected ''/var/www/vhosts/................' (T_ENCAPSED_AND_WHITESPACE) | ParseError thrown in file /var/www/vhosts/.............../....................../web/typo3temp/assets/bootstrappackage/lessphp_ng44dxe9mhc840cg80cocs00s8k8wko.lesscache in line 1. Requested URL: http://......................./index.php?id=2
Updated by Susanne Moog about 4 years ago
- Status changed from New to Needs Feedback
I still cannot reproduce this issue - the last comment hints at the bootstrap package / less parsing with low memory, the previous error messages hinted at something I have only ever seen on deployment scripts (after clearing the cache, the package states is rebuilt with the currently on the filesystem available packages, if it's in the middle of a deployment, some are missed).
Does anyone have a way to reproduce this on a really clean TYPO3 (without introduction / bootstrap etc?)?
Updated by Riccardo De Contardi about 3 years ago
- Status changed from Needs Feedback to Closed
No feedback since the last 90 days => closing this issue.
If you think that this is the wrong decision or experience the issue again and have more information about how to reproduce your problem, please reopen it or open a new issue with a reference to this one.
Thank you and best regards.