TYPO3 Core

I confirm this bug in the most current svn 4.3:

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

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/

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?

Can somebody please point me on how to reproduce this issue?

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.

I just deleted every image in the typo3temp folder and the warning occured.

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.

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)

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;
                }

Patch "t3lib_lock.patch" works for me.

trunk rev 9063