Project

General

Profile

Actions

Bug #57463

closed

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

Added by Alexander Opitz almost 10 years ago. Updated over 5 years ago.

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

100%

Estimated time:
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.


Files

2015-02-17_13-35-46.jpg (124 KB) 2015-02-17_13-35-46.jpg Mohamed Masmoudi, 2015-02-17 13:36

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #57464: Upgrading 6.2: PHP Fatal error: [...]/typo3update/typo3conf/LocalConfiguration.php is not writable.Closed2014-03-31

Actions
Related to TYPO3 Core - Bug #57008: New Installation: Could not acquire lock for ClassLoaderClosed2014-03-17

Actions
Related to TYPO3 Core - Bug #61900: ClassLoader: Stalled Lock file if ClassLoader caching fails.ClosedAlexander Opitz2014-09-26

Actions
Actions #1

Updated by Alexander Opitz almost 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.
Actions #2

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

Actions #3

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

Actions #4

Updated by Alexander Opitz almost 10 years ago

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

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

Actions #6

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

Actions #7

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

Actions #8

Updated by Philipp Gampe over 9 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.

Actions #9

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

Actions #10

Updated by Stephan Bauer over 9 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

Actions #11

Updated by Alexander Opitz over 9 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.

Actions #12

Updated by Roman Eberle over 9 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? ...

Actions #13

Updated by Dieter Porth over 9 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

Actions #14

Updated by Hendrik Effing over 9 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

Actions #15

Updated by Alexander Opitz over 9 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.

Actions #16

Updated by Alexander Opitz over 9 years ago

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

Actions #17

Updated by Kurt Gusbeth over 9 years ago

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

Actions #18

Updated by Florian Seirer over 9 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.

Actions #19

Updated by Alexander Opitz over 9 years ago

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

Actions #20

Updated by Florian Seirer over 9 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.

Actions #21

Updated by Alexander Opitz over 9 years ago

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

Actions #22

Updated by Enrico Noack over 9 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

Actions #23

Updated by Alexander Opitz over 9 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.

Actions #24

Updated by Enrico Noack over 9 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.

Actions #25

Updated by Markus Günther over 9 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
Actions #26

Updated by Alexander Opitz over 9 years ago

@Markus Günther

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

Actions #27

Updated by David Bruchmann about 9 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.

Actions #28

Updated by Mohamed Masmoudi about 9 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

Actions #29

Updated by Marc Willmann about 9 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...

Actions #30

Updated by Alexander Opitz about 9 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.

Actions #31

Updated by Mohamed Masmoudi about 9 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.

Actions #32

Updated by Sebastian Fuchs about 9 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).

Actions #33

Updated by Alexander Opitz about 9 years ago

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

Actions #34

Updated by Mohamed Masmoudi about 9 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

Actions #35

Updated by Lorenzo Kappeler about 9 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

Actions #36

Updated by Alexander Opitz about 9 years ago

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

Actions #37

Updated by Lorenzo Kappeler about 9 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.

Actions #38

Updated by Alexander Opitz about 9 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.

Actions #39

Updated by Alexander Opitz about 9 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.

Actions #40

Updated by Arek van Schaijk almost 9 years ago

nvm

Actions #41

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF