Bug #32282
closed
typo3temp/locks warning. unlink function returns warning
Added by Razakanirina over 12 years ago.
Updated almost 6 years ago.
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
- Status changed from New to Under Review
I've seen this behaviour and I'm currently trying to figure out what the cause is. I suspect some race condition.
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.
Does testing if file exists solve the race condition problem? Does it related to the php unlink() function?
- 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.
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)
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...
- Status changed from Needs Feedback to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Under Review
- Status changed from Under Review to Resolved
- Status changed from Resolved to Under Review
- Status changed from Under Review to Resolved
- Status changed from Resolved to Closed
Also available in: Atom
PDF