bug #52201 [HttpKernel] Resolve EBADP error on flock with LOCK_SH with NFS (driskell)

fabpot · fabpot · commit c4558e756ddd · 2023-10-20T18:07:43.000+02:00
This PR was merged into the 5.4 branch. Discussion ---------- [HttpKernel] Resolve EBADP error on flock with LOCK_SH with NFS | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #52144 | License | MIT When using NFSv3 (with rpc.statd with NLM) or NFSv4, or any other filesystem where flock is converted to fcntl, performing flock LOCK_SH due to a would-be-blocking LOCK_EX will trigger EBADP and return false, and bypass the cache lock, due to the lock file not being opened with read mode. This causes cache locking to not have any effect on these filesystems. Changing the lock file open to w+ resolve this issue and makes cache locking effective on NFS and other similar filesystems which convert flock calls to fcntl. As per fcntl documentation: In order to place a read lock, fd must be open for reading. In order to place a write lock, fd must be open for writing. To place both types of lock, open a file read-write. Commits ------- 8be417d [HttpKernel] Resolve EBADP error on flock with LOCK_SH with NFS
diff --git a/src/Symfony/Component/HttpKernel/Kernel.php b/src/Symfony/Component/HttpKernel/Kernel.php
@@ -467,7 +467,7 @@ protected function initializeContainer()
         try {
             is_dir($buildDir) ?: mkdir($buildDir, 0777, true);
 
-            if ($lock = fopen($cachePath.'.lock', 'w')) {
+            if ($lock = fopen($cachePath.'.lock', 'w+')) {
                 if (!flock($lock, \LOCK_EX | \LOCK_NB, $wouldBlock) && !flock($lock, $wouldBlock ? \LOCK_SH : \LOCK_EX)) {
                     fclose($lock);
                     $lock = null;
