Bug #19112
closedunlink of non existing lockfiles generates warnings in frontend
0%
Description
Warning: unlink(<stipped>/typo3temp/locks/489893f2c580c9c27eefb8733ad52a36) [function.unlink]:
No such file or directory in <stipped>/t3lib/class.t3lib_lock.php on line 216
in line 216 of t3lib/class.t3lib_lock.php a lockfile is removed without checking. If the lockfile doesn't exist a php warning is generated.
(issue imported from #M8980)
Files
Updated by Franz Holzinger over 15 years ago
I confirm this bug in the most current svn 4.3:
( ! ) Warning: unlink(/var/www/html/mike/typo3temp/locks/f9669f0b1ad272ade2dcaa4388b2d185) [function.unlink]: No such file or directory in /var/www/html/trunk/t3lib/class.t3lib_lock.php on line 216Call Stack
- Time Memory Function Location
1 0.0159 131016 {main}( ) ../index.php:0
2 0.0239 376896 require( '/var/www/html/trunk/typo3/sysext/cms/tslib/index_ts.php' ) ../index.php:76
3 3134.2897 62672096 tslib_fe->generatePage_postProcessing( ) ../index_ts.php:421
4 3135.1756 62690864 tslib_fe->releasePageGenerationLock( ) ../class.tslib_fe.php:3065
5 3135.1757 62690864 t3lib_lock->release( ) ../class.tslib_fe.php:2895
6 3135.1838 62690864 unlink ( ) ../class.t3lib_lock.php:216
Updated by Martin Holtz over 15 years ago
i had that error too
with configuration:
$TYPO3_CONF_VARS['SYS']['lockingMode'] = 'flock'
and
$TYPO3_CONF_VARS['SYS']['lockingMode'] = 'simple'
Warning: unlink(/var/www/html/testsystem/typo3temp/locks/d412726f8e33176eab8b7e9f568ecf9f) [function.unlink]: No such file or directory in /var/www/html/typo3_src-4.2.6/t3lib/class.t3lib_lock.php on line 225
Warning: unlink(/var/www/html/testsystem/typo3temp/locks/d885c3dbc400d55d9df937b870d164a3) [function.unlink]: No such file or directory in /var/www/html/typo3_src-4.2.6/t3lib/class.t3lib_lock.php on line 225
i am wondering why there are two differen locks while rendering one page?
fyi: there is no file left in typo3temp/locks/
Updated by Leonhard Wimmer about 15 years ago
I can confirm this problem on servers with error_reporting=On.
This should be quite easy to fix but is "New" nearly a year now. Is there a chance this is going to be fixed soon?
Updated by Benni Mack about 15 years ago
Can somebody please point me on how to reproduce this issue?
Updated by Thomas Schröder about 15 years ago
Playing arround with APC and memcached I also get such errors. I did a wget -m several times over the website. After a few runs for some pages the http-request took some minutes before the error was logged.
Right now I can not reproduce it exactly.
Updated by Tobias Eichelberger about 15 years ago
I just deleted every image in the typo3temp folder and the warning occured.
Updated by Martin Holtz almost 15 years ago
Reproduce this issue:
1. Clear cache
2. request the same page twice
But: you need a page which takes some times to render, it helps if you put a lot of typoscript on that page, perhaps use cal and powermail etc. So there is a higher chance to get a collision.
Updated by Andy Kittner almost 15 years ago
I believe this is a race-condition when acquiring the lock: In the time between is_file() returning False and touch creating the lock another process does the same. In the end two processes try to unlink the lockfile (beside the fact that whatever uses the lock isn't protected against parallel access).
I can reproduce this even with a simple hello-world dummy page, just set config.no_cache = 1 in the template and hammer the server with request (20 processes repeatedly starting curl to fetch the url worked well on my old P4)
If I change the algorithm to use fopen("x") instead of is_file & touch everything works as expected
(see attached patch)
Updated by Dierk Scharbert over 14 years ago
I patched class.t3lib_lock.php as follows in the T3 System I use. The existance of the resource should be checked first:
if (file_exists($this->resource))
{
if (unlink($this->resource) == false)
{
$success = false;
}
}
else
{
$success = false;
}