Project

General

Profile

Actions

Bug #32282

closed

typo3temp/locks warning. unlink function returns warning

Added by Razakanirina over 12 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-12-03
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

php unlink() function returns a warning when the file does not exist.

Obtained warning:
---
Core: Error handler (FE): PHP Warning: unlink(/.../.../typo3temp/locks/107c9b0324ec9db67812eb6af3e78732) [<a href='function.unlink'>function.unlink</a>]: No such file or directory in /usr/local/src/typo3/typo3_src-4.5.8/t3lib/class.t3lib_lock.php line 210

We should test the $this->resource variable by file_exists() php function before unlinking.

if (unlink($this->resource) == FALSE) {


Files


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #19112: unlink of non existing lockfiles generates warnings in frontendClosedMartin Kutschker2008-07-16

Actions
Related to TYPO3 Core - Bug #40420: Semaphore based locking returns warningClosed2012-08-30

Actions
Is duplicate of TYPO3 Core - Bug #24342: t3lib_lock still sometimes has a race condition on deleting locks.Closed2010-12-15

Actions
Actions #1

Updated by Gerrit Code Review over 12 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/7052

Actions #2

Updated by Xavier Perseguers over 12 years ago

I've seen this behaviour and I'm currently trying to figure out what the cause is. I suspect some race condition.

Actions #3

Updated by Björn Pedersen over 12 years ago

This is a race condition reported here already:
http://forge.typo3.org/issues/24342

Actions #4

Updated by Xavier Perseguers over 12 years ago

There is indeed a problem that appears when the lock file could not be acquired, as reported in this syslog (after slightly modifying Core to add additional information):

05-12-11 15:24 - cms: Locking: Failed to acquire lock: Lock file could not be created
(/path/to/typo3temp/locks/f288221509d8f33b8e85fbfd25731733)
05-12-11 15:24 - Core: Error handler (FE): PHP Warning: unlink(/path/to/typo3temp/locks/
f288221509d8f33b8e85fbfd25731733) [<a href='function.unlink'>function.unlink</a>]: No such
file or directory in /path/to/t3lib/class.t3lib_lock.php line 21

The non-acquired lock-file is then "unlinked" by taking for granted that it exists. By quickly digging into the code, I'd say that fixing that would require quite some refactoring of t3lib_lock, refactoring that is supposed to happen with #24342 but was forgotten (as not pushed forwards) for 4.6, thus hopefully something for 4.7.

Anyway, I would suggest to simply test for file existence before unlinking it but not hide the warning with an @ sign in front of unlink.

Actions #5

Updated by Razakanirina over 12 years ago

Does testing if file exists solve the race condition problem? Does it related to the php unlink() function?

Actions #6

Updated by Helmut Hummel over 12 years ago

  • Status changed from Under Review to Needs Feedback

For those who have problems with the unlink warning message:

What is your max_execution_time setting?

The only reace condition which is clearly there is because of deleting stale lock files.

Actions #7

Updated by Helmut Hummel over 12 years ago

I added a small extension to reproduce the problem.

Install it, then execute the following command line:

wget -qO- "http://typo3.dev/index.php?eID=locktest&number=first" & sleep 2; wget -qO- "http://typo3.dev/index.php?eID=locktest&number=second" 

The problem will occur, when the max_execution_time is relatively low (forced to be 1 second in the extension), but the request itself takes longer than the max_execution_time

This may well happen because max_execution_time only reflects the PHP script execution times but excludes the time that is consumed by single commands (like sleep or other system commands)

Actions #8

Updated by Xavier Perseguers over 12 years ago

What about adding the @ sign in front of unlink instead of testing with file_exists. I'd say that even if not "that clean", it will prevent perform 2 accesses for the file system in most cases...

Actions #9

Updated by Gerrit Code Review about 12 years ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/9612

Actions #10

Updated by Markus Klein about 12 years ago

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

Updated by Gerrit Code Review over 11 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch TYPO3_4-5 has been pushed to the review server.
It is available at http://review.typo3.org/12831

Actions #12

Updated by Gerrit Code Review over 11 years ago

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/12832

Actions #13

Updated by Markus Klein over 11 years ago

  • Status changed from Under Review to Resolved
Actions #14

Updated by Gerrit Code Review over 11 years ago

  • Status changed from Resolved to Under Review
Actions #15

Updated by Oliver Hader over 11 years ago

  • Status changed from Under Review to Resolved
Actions #16

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF