Bug #57463
closedUpgrading 6.2: PHP Fatal error: Could not acquire lock for ClassLoader cache creation.
100%
Description
PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.' in [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/ClassLoader.php:723 Stack trace: #0 [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/ClassLoader.php(239): TYPO3\\CMS\\Core\\Core\\ClassLoader->acquireLock() #1 [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/ClassLoader.php(176): TYPO3\\CMS\\Core\\Core\\ClassLoader->buildCachedClassLoadingInformation('typo3_cms_core_...', 'TYPO3\\CMS\\Core\\...') #2 [internal function]: TYPO3\\CMS\\Core\\Core\\ClassLoader->loadClass('TYPO3\\CMS\\Core\\...') #3 [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/Bootstrap.php(316): spl_autoload_call('TYPO3\\CMS\\Core\\...') #4 [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/Bootstrap.php(233): TYPO3\\CMS\\Core\\Core\\Bootstrap->initializePackageManagement('TYPO3\\CMS\\Core\\...') #5 [...]/typo3update/typo3-src in [...]/typo3update/typo3-src/typo3/sysext/core/Classes/Core/ClassLoader.php on line 723
If typo3temp exists, we should also check if it is writable. If we try to acquire a lock this will fail, cause we think this look can't be acquired as someone else have it which isn't true.
Files
Updated by Alexander Opitz over 10 years ago
- Subject changed from Upgrading 6.2: PHP Fatal error: Uncaught exception 'RuntimeException' to Upgrading 6.2: PHP Fatal error: Could not acquire lock for ClassLoader cache creation.
Updated by Gerrit Code Review over 10 years ago
- Status changed from New 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/28988
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/28988
Updated by Alexander Opitz over 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset ae7f6bbd4e12f58549bc009e7b087d4e94fe9214.
Updated by Brian Lynch over 10 years ago
I have installed the new Locker.php file and still have the exact same error, starting with: HP Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.
and including the same final line ending in ...ClassLoader.php on line 723. (different paths of course)
I have two web sites running in separate sub-directories, one works and one does not. I have tired to clear temp files check permissions, etc. and nothing seems to help.
Website does not work, backend does not work, and install does not work. Same Error on all three.
I think this problem may still persist, maybe there is another cause, it's not permissions, I have checked against the running site, and I have relaxed permissions on the site that is not running, no change.
Ideas to check?
Updated by Alexander Opitz over 10 years ago
Hi Brian,
you can take a look into the Locker.php itself. The function acquireExclusiveLock seems to return FALSE. As the Locker for ClassLoader uses LOCKING_METHOD_SIMPLE you only need to check this part.
At first it tries to identify lockfiles which are stale (this means not used anymore but not removed ... why ever this happens). In the second part (the for loop) it tries to create the look file until it works or a timeout happens.
You may try to remove the @ before the fopen and check your log files why this fopen fails.
Updated by Alexander Schnitzler over 10 years ago
I just had the same issue with a fresh cloned TYPO3 6.2.3 source, running typo3/sysext/install/Start/Install.php from cli.
I want to build a CI environment for testing extensions, so I need to to call the Install.php to have a PackageStates.php created by the system. Anyway, it's not possible to run Install.php from cli. The issue with the lock file is, that it is created once and the Locker.php tries to create (fopen(... ,'x')) it a second time.
So I do not consider this issue solved.
Updated by Philipp Gampe over 10 years ago
The issue here is that the class loader fails without a lock, but actually it should just move on and skip writing cache entries.
Updated by Philipp Idler over 10 years ago
I have had this issue too. Tried to upgrade a 6.2.1 installation to 6.2.4.
After updating php from 5.3.x to 5.4.x everything works as expected.
Perhaps this helps.
Updated by Stephan Bauer over 10 years ago
Same problem here:
Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.' in /data/www/web7/htdocs/secure-registration/typo3_src-6.2.5beta/typo3/sysext/core/Classes/Core/ClassLoader.php:710
Updated by Alexander Opitz over 10 years ago
As I already wrote, please check following and report back:
you can take a look into the Locker.php itself. The function acquireExclusiveLock seems to return FALSE. As the Locker for ClassLoader uses LOCKING_METHOD_SIMPLE you only need to check this part. At first it tries to identify lockfiles which are stale (this means not used anymore but not removed ... why ever this happens). In the second part (the for loop) it tries to create the look file until it works or a timeout happens. You may try to remove the @ before the fopen and check your log files why this fopen fails.
Updated by Roman Eberle over 10 years ago
i'm having this bug with
TYPO3 6.2.4 (no patches)
Apache/2.4.9 (Fedora) PHP/5.5.15
UPDATE:
bug resolved here, turned out to be extension related.
rebuilt extension "from scratch", based on femanagerextended_0.1.2
changed that may have helped resolving bug:
- db-field int(16) changed to varchar(255) in ext_tables.sql
- fixed wrong $TCA table index in ext_tables.php
- removed Configuration/Typoscript/setup.txt (using ext_typoscript_setup.txt)
- created empty folder Classes/Domain/Repository
=> conclusion: typoscript error? wrong TCA config? ...
Updated by Dieter Porth over 10 years ago
I get this error too - with TYPO3 6.2.3.
I think, I changed an entry in the installtool and then the error occur. Nothing works. No backend, No Installtool, No frontend.
I tried the typical actions.
Hours later:
I deleted the file "PackageStates.php" in the directory "typo3conf". After that the system works fine.
I don't know, if that was the location of the error.
I can't check it. I don't make a copy of that file while the error occurs the first time.
Dieter
Updated by Hendrik Effing over 10 years ago
I had the same error today, TYPO3 6.2.4 on PHP 5.3.29, no FE, no BE Login possible, Exception like described. Tried different solutions, the last one seemed to solve the problem for me: rm all files in typo3temp/locks.
Maybe this helps to find a solution.
Hendrik
Updated by Alexander Opitz about 10 years ago
I'm listening in this issue, but yet I miss more information. Words like "Tried different solutions" and "I tried the typical actions." do not help me to get to the point, why does it happen.
Cores ClassLoader will do following (in simple words):
- If class cache needs to be rewritten, a lock will be requested. In TYPO3 6.2 only SimpleFile lock will be used by ClassLoader.
- The SimpleFile lock creates a file in typo3temp/locks
- After this could be done, the class cache will be generated
- Afterwards SimpleFile is requested to release this lock
- Requests (read and write) which come in while the lock exists will wait some time till the exception is thrown.
- If the lock file is older then PHPs max_execution_time (or 120 seconds if not set) it will be removed automatically.
Nitpicks in this handling are multi server TYPO3 CMS systems, which use NFS (or similar) for their typo3temp, as the file existence or directory content is mostly cached inside the NFS client, which leads to unpredictable results for the lock file.
There is a blueprint to change the source code of the lock file handling as the yet existing source code isn't good manageable for developers. But the rewrite won't help us, why this issue happen.
So there are multiple questions:
- Why does the class loader do not end building his class cache and releases the lock? Does it fatal with an exception and forget to clean up the lock?
- Why is the lock not removed automatically? It seams some of you users try it a longer time.
- Can it be that the lock file was generated from another user or does it maybe have wrong permissions for the web user to remove it later? (First call from CLI second from Webserver?)
- Does this happens only on upgrade of your TYPO3 CMS system? If yes, what are the last things you did?
Hopefully this helps someone to find the issue on his system or can describe a reproduceable way for me.
Updated by Alexander Opitz about 10 years ago
First time I got a way, the described issue can happen. Please see the new report for this: #61900
Updated by Kurt Gusbeth about 10 years ago
I got the same error message after uploading an extension in Typo3 6.2.6.
Updated by Florian Seirer about 10 years ago
Same error here.
FE dead, BE dead, Install Tool dead after going from 6.2.4 to 6.2.6.
I also saw that all currently installed core extensions were missing from /typo3conf/packageStates.php.
The file started with the local extensions, and then all the not installed extensions.
No wonder nothing was working.
But even a working packageStates.php which I copied from the 6.2.4 backup didn't solve the problem on 6.2.6, so I had to revert back to 6.2.4.
Updated by Alexander Opitz about 10 years ago
As the PackageStates.php isn't touched in the process of creating ClassLoader cache, it seams something else is broken on your system.
And "dead" doesn't help me to understand your issue, I need error messages from the log files.
Updated by Florian Seirer about 10 years ago
I just tried this again on another installation, and the end result is the same (fatal error in FE and BE, packageStates.php missing active core extensions).
But the error messages changed, so I will add a post to https://forge.typo3.org/issues/57120 instead.
Updated by Alexander Opitz about 10 years ago
That looks like the issue which leads you to this issue. It sounds like you need to clear opcode cache, after changing the symlink.
Updated by Enrico Noack about 10 years ago
I got the same error after installing some extensions (pt_extbase, pt_extlist). I tried to resolve that by patching with https://review.typo3.org/#/c/32982/ but it still happens.
Typo3 6.2.6
Here the censored Stacktrace
06.11.2014 21:13:39 [url] FastCGI: "[...]/htdocs/neu_waldhoehe/typo3/ajax.php" aborted: incomplete headers (0 bytes) received from server after 60 sec, referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.' in [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php:718, referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] Stack trace:, referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #0 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php(232): TYPO3\\CMS\\Core\\Core\\ClassLoader->acquireLock(), referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #1 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php(169): TYPO3\\CMS\\Core\\Core\\ClassLoader->buildCachedClassLoadingInformation('typo3_cms_core_...', 'TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #2 [internal function]: TYPO3\\CMS\\Core\\Core\\ClassLoader->loadClass('TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #3 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/ext_localconf.php(11): spl_autoload_call('TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #4 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php(1529): require('/mnt/webi/b0/29...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:14:09 [url] #5 [...]/htdocs/typo3_src-6.2.6/typo3/sys in [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php on line 718, referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Could not acquire lock for ClassLoader cache creation.' in [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php:718, referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] Stack trace:, referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #0 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php(232): TYPO3\\CMS\\Core\\Core\\ClassLoader->acquireLock(), referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #1 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php(169): TYPO3\\CMS\\Core\\Core\\ClassLoader->buildCachedClassLoadingInformation('typo3_cms_core_...', 'TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #2 [internal function]: TYPO3\\CMS\\Core\\Core\\ClassLoader->loadClass('TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #3 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/ext_localconf.php(11): spl_autoload_call('TYPO3\\CMS\\Core\\...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #4 [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php(1529): require('/mnt/webi/b0/29...'), referer: http://[url]/typo3/backend.php 06.11.2014 21:15:09 [url] #5 [...]/htdocs/typo3_src-6.2.6/typo3/sys in [...]/htdocs/typo3_src-6.2.6/typo3/sysext/core/Classes/Core/ClassLoader.php on line 718, referer: http://[url]/typo3/backend.php
Updated by Alexander Opitz about 10 years ago
@Enrico
The patch doesn't help after the issue already happened. But please take a look into your logfiles and search for the issue which happened while installing the extensions. This should be shortly before the error about the lock file.
Updated by Enrico Noack about 10 years ago
@Alexander
Ther error before was
PHP Fatal error: Class 'template' not found in [...]/htdocs/waldhoehe/t3lib/class.t3lib_div.php on line 4847, referer:[url]/typo3/backend.php
but i dont think that one is related to the bug.
I will try to reproduce the error with deleted errorlog and will post the result here shortly.
Updated by Markus Günther about 10 years ago
I also got this error today after a provision of my vagrant machine ... The comment of Alex helped me alot. In typo3temp/lock a file already existed and so the error came up.
It is not much information, but maybe it helps a bit.
PHP Warning: fopen(/var/www/test.dev/typo3temp/locks/0df7b553fc410fe7418c41d6290d81c6): failed to open stream: File exists in /var/www/test.dev/typo3_src-patched/typo3/sysext/core/Classes/Locking/Locker.php on line 266
Updated by Alexander Opitz about 10 years ago
@Markus Günther
Thanks, but this don't help, there must be something before that message. ;)
Updated by David Bruchmann almost 10 years ago
Trying to update from 4.5.37 to 6.2.9 I get the same error after disabling incompatible extensions.
As 6.2.9 is not yet so old it seems any bugfixes never found their way in the new version.
After deleting the lock-file in typo3temp/locks I can proceed now.
Updated by Mohamed Masmoudi almost 10 years ago
- File 2015-02-17_13-35-46.jpg 2015-02-17_13-35-46.jpg added
Hello,
i always have this issue after a new fresh install of 6.2.9 (download pre-distribution) and get to the extension manager. any help ?
Thanks,
best regards
Updated by Marc Willmann almost 10 years ago
TSniper - any NFS involved in your setup? I have solved this issue for my setup by do not using NFS for typo3temp anymore... seems to be a race condition bug which is only relevant in some NFS (or similar) setups...
Updated by Alexander Opitz almost 10 years ago
Since integration of #61900 in 6.2.7 the lock file should be removed also after a crash while generating the cache.
So the question would be, what happened before so that the lock file wasn't removed. Please check your logfiles and check your typo3temp FS. Please also take a look into comment 15 in this issue.
Updated by Mohamed Masmoudi almost 10 years ago
Marc Willmann wrote:
TSniper - any NFS involved in your setup? I have solved this issue for my setup by do not using NFS for typo3temp anymore... seems to be a race condition bug which is only relevant in some NFS (or similar) setups...
I'm using it under windows7 wamp 2.5 apache 2.4.9.
Updated by Sebastian Fuchs almost 10 years ago
Same problem here. Fresh installation of TYPO3 6.2.9 (php 5.3.x).
The error message comes during work with extension manager.
We could fix this by disabling suhosin completly for this vhost (before suhosin was running with exec etc. enabled).
Updated by Alexander Opitz almost 10 years ago
Yes, nice that this issue happens to you. But I need other information. Please read my comments, especially comment 15.
Updated by Mohamed Masmoudi almost 10 years ago
Alexander Opitz wrote:
Yes, nice that this issue happens to you. But I need other information. Please read my comments, especially comment 15.
Hi Alexander,
Thank for the explication, but i didn't understand this "Nitpicks in this handling are multi server TYPO3 CMS systems, which use NFS (or similar) for their typo3temp, as the file existence or directory content is mostly cached inside the NFS client, which leads to unpredictable results for the lock file.".
I'm just using the latest wamp version 2.5 x64 and a fresh install typo3 6.2.9. just had clicked to choose the pre-installed t3bootstrap package to install it.
best greets
Updated by Lorenzo Kappeler almost 10 years ago
I'm currently running into the same Issue.
According to http://wiki.typo3.org/Autoload I accidentally implemented the Autoloader for a Extension with Namespaces.
This is not necessary at all because as you can read at http://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Autoloading/Index.html
The examples below are related to non-namespaced classes. When using namespaces, autoloading will happen without any extra effort on your part.
Hope this helps you to reproduce the Error.
System:
TYPO3 6.2.6
Apache/2.2.15 (Unix)
Linux (CentOS) 2.6.32-431.23.3.el6.x86_64
Native Filesystem
Apche-User can write cache files and is owner of the written/created files
Updated by Alexander Opitz almost 10 years ago
On windows I think you won't have NFS, so this won't be your issue. But please, take a look into your error logfiles to see, what happens before this error occurs and why the lock file isn't removed.
@Lorenzo
The problem is not writing/creating the cache files. The issue is, why isn't the lock removed after the real error occurred. Please take a look into your log files, if there is something which may help me.
Updated by Lorenzo Kappeler almost 10 years ago
@Alexander
The PHP- and Access-Log files says nothing about the error and the Error-Log prints the same as already posted in the Ticket description.
Thats why i didn't posted the Stack Trace. My Intention was, according to #15 describe a Way to reproduce the Error.
Updated by Alexander Opitz almost 10 years ago
But we need to find the issue, why the lock file doesn't get removed. We don't need to play around if the file isn't removed.
Updated by Alexander Opitz almost 10 years ago
For example, if PHP dies unexpectedly you may find this in /var/log/messages ... but then we can't do anything against this.