TYPO3 Core

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

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?

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.

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.

The issue here is that the class loader fails without a lock, but actually it should just move on and skip writing cache entries.

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.

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

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.

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? ...

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

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

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.

First time I got a way, the described issue can happen. Please see the new report for this: #61900

I got the same error message after uploading an extension in Typo3 6.2.6.

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.

@Florian Kuss

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.

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.

@Florian Kuss

That looks like the issue which leads you to this issue. It sounds like you need to clear opcode cache, after changing the symlink.

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

@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.

@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.

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

@Markus Günther

Thanks, but this don't help, there must be something before that message. ;)

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.

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...

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.

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.

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).

Yes, nice that this issue happens to you. But I need other information. Please read my comments, especially comment 15.

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

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

@Mohamed Masmoudi

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.

@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.

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.

For example, if PHP dies unexpectedly you may find this in /var/log/messages ... but then we can't do anything against this.

nvm