Bug #57463

Upgrading 6.2: PHP Fatal error: Could not acquire lock for ClassLoader cache creation.

Added by Alexander Opitz almost 5 years ago. Updated 5 months ago.

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

100%

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

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.

2015-02-17_13-35-46.jpg View (124 KB) TSniper no-lastname-given, 2015-02-17 13:36


Related issues

Related to TYPO3 Core - Bug #57464: Upgrading 6.2: PHP Fatal error: [...]/typo3update/typo3conf/LocalConfiguration.php is not writable. New 2014-03-31
Related to TYPO3 Core - Bug #57008: New Installation: Could not acquire lock for ClassLoader Closed 2014-03-17
Related to TYPO3 Core - Bug #61900: ClassLoader: Stalled Lock file if ClassLoader caching fails. Closed 2014-09-26

Associated revisions

Revision ae7f6bbd (diff)
Added by Alexander Opitz almost 5 years ago

[BUGFIX] Check if lock directory is writable

We should check if directory is writable. Else fopen in acquireLock
would only fail with error after waiting time. Also we do not aspect
write permission issue here.

Resolves: #57463
Releases: 6.2
Change-Id: Ia767a2355aecf1e816d4c130b151443e50e1a311
Reviewed-on: https://review.typo3.org/28988
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Stefan Neufeind
Tested-by: Stefan Neufeind

History

#1 Updated by Alexander Opitz almost 5 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.

#2 Updated by Gerrit Code Review almost 5 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

#3 Updated by Gerrit Code Review almost 5 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

#4 Updated by Alexander Opitz almost 5 years ago

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

#5 Updated by Brian Lynch almost 5 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?

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

#7 Updated by Alexander Schnitzler over 4 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.

#8 Updated by Philipp Gampe over 4 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.

#9 Updated by Philipp Idler over 4 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.

#10 Updated by Stephan Bauer over 4 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

#11 Updated by Alexander Opitz over 4 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.

#12 Updated by Roman Eberle over 4 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? ...

#13 Updated by Dieter Porth over 4 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

#14 Updated by Hendrik Effing over 4 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

#15 Updated by Alexander Opitz over 4 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.

#16 Updated by Alexander Opitz over 4 years ago

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

#17 Updated by Kurt Gusbeth over 4 years ago

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

#18 Updated by Florian Seirer over 4 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.

#19 Updated by Alexander Opitz over 4 years ago

@Florian

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.

#20 Updated by Florian Seirer over 4 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.

#21 Updated by Alexander Opitz over 4 years ago

@Florian

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

#22 Updated by Enrico Noack over 4 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

#23 Updated by Alexander Opitz over 4 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.

#24 Updated by Enrico Noack over 4 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.

#25 Updated by Markus Günther over 4 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

#26 Updated by Alexander Opitz over 4 years ago

@Markus Günther

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

#27 Updated by David Bruchmann about 4 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.

#28 Updated by TSniper no-lastname-given almost 4 years ago

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

#29 Updated by Marc Willmann almost 4 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...

#30 Updated by Alexander Opitz almost 4 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.

#31 Updated by TSniper no-lastname-given almost 4 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.

#32 Updated by Sebastian Fuchs almost 4 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).

#33 Updated by Alexander Opitz almost 4 years ago

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

#34 Updated by TSniper no-lastname-given almost 4 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

#35 Updated by Lorenzo Kappeler almost 4 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

#36 Updated by Alexander Opitz almost 4 years ago

@TSniper

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.

#37 Updated by Lorenzo Kappeler almost 4 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.

#38 Updated by Alexander Opitz almost 4 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.

#39 Updated by Alexander Opitz almost 4 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.

#40 Updated by Arek van Schaijk almost 4 years ago

nvm

#41 Updated by Benni Mack 5 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF