Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HttpKernel] Resolve EBADP error on flock with LOCK_SH with NFS #35

Closed
wants to merge 1 commit into from

Conversation

driskell
Copy link
Contributor

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.

Fixes symfony/symfony#52144

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.
@github-actions
Copy link

Thanks for your pull request! We love contributions.

However, you should instead open a pull request on the main repository:

https://github.com/symfony/symfony

This repository is what we call a "subtree split": a read-only subset of that main repository.

We're looking forward to your PR there!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant