-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Use flock for the upgrade lock #1903
Comments
I would love a "yay" and "nay" on this before I dig into the test failure at #1905 😅 |
I closed #1757 because @skjnldsv's change meant I could just ignore / work around the problem by not using "Yay" from me to continue work on this. I'm not a maintainer, just a Nextcloud enthusiast/contributor. It would be a Good Thing to use some kind of ephemeral lock rather than the one requiring user intervention. If
Ah, this removes some of the uncertainty around my patch in #1757, thanks. Good call to put the lockfile in |
fix nextcloud#1756 fix nextcloud#1903 Signed-off-by: Adam Monsen <haircut@gmail.com>
re: this con:
Agreed. In either case you'll have a broken server and would need to inspect the logs for errors. |
In #1757, an attempt was made at replacing the locking mechanism for upgrade (when running multiple containers) from simply creating a file to using Linux advisory locks with flock. Admittedly the patch had a few flaws.
Eventually the MR was closed in favor of making the locking optional with an environment variable in #1760. This is a very different approach, but it resolves the issue you had at the time, #1742.
I am opening this issue to gauge whether the is still interest in using flock rather than the mere presence of the file, e.g. did you close #1757 because you don't want to do that, or simply because it was not ready and another patch was able to fix the pressing upgrade issue in #1742?
Pros of using flock:
Cons of using flock:
The text was updated successfully, but these errors were encountered: