-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Race condition with locks in database - unique constraint violation on oc_file_locks #9305
Comments
bump |
Current Nextcloud version is 13.0.2 – does your issue still occur with NC13? |
Yes, it does. |
Yes, I had to move to mariadb. |
But I also have PostgreSQL and cannot reproduce it. 😉 |
@benedikt Do you use LDAP? Do you have Nextcloud behind a web proxy? Is the Nextcloud under some load (few users using it concurrently)? This is apparently some race condition, so hard to reproduce in testing environment. |
@benediktg it's extremely hard to reliably reproduce, however I had it happen with 2 tabs + the android client running in the same time. Using redis fixes it so it is definitely a race issue with *SQL. |
Ah, I also have redis (for transactional file locking).
no; php-fpm behind nginx here; usually I use it alone. |
In more recent versions (13.0.4 and 12.0.9) we reduced drastically the amount of lock statements which should avoid most of the problems in here. Maybe also this one here is related: #8239 |
Crossposting from #8239: Is it possible to get a file locking debug log? There is a config switch that - once set - will log all locking attempts. Maybe we can pinpoint then the actual problem. Would one of you so kind to provide this log as we are unable to reproduce the issue on our side. You maybe want to combine this Thanks in advance. |
@MorrisJobke the problem persists in 13.0.4 |
This looks like it could be fixed by #10116. That one avoids, that more locks are freed than there are (the lock is usually the count of existing locks and |
Could we get a bug fix out soon? |
Plan is to backport it, but testing from your side may help to know if this is a fix for your problem or if we still need to check for further places as well. |
Just had a proper look at pull request #10116 and that wont help me, I dont use memcache for locking. |
Okay. Then we should check for the same in the DB provider. |
Just in case it helps with debug Nextcloud configuration: Config report
|
Does the Protocoll shows references to Adapter.php LINE 115 like: If so - maybe you want to check my solution in #6160 for testing - i think the problem is in general using update and select together on one table which should work, but sometimes doesn't (at least for me). |
Fix is in #12366 |
So until I upgrade to Nextcloud 15 which has this fix, what are the consequences of this error on version 14? Will the desktop client on Windows eventually be able to upload those files? Or is this dangerous, because some files do not get synced? |
We try to backport fixes for this as well to stable14. |
* fixes #9305 by not being prone to the race condition in insertIfNotExists * fixes #6899 by not using a query that can result in a deadlock * replaces the insertIfNotExists call with an insert which is wrapped into a try-catch block * followup to #12371 Signed-off-by: Morris Jobke <[email protected]>
See #12413 for the fix to this issue (it fixes the race condition with the unique constraint violation and the deadlock) |
* fixes #9305 by not being prone to the race condition in insertIfNotExists * fixes #6899 by not using a query that can result in a deadlock * replaces the insertIfNotExists call with an insert which is wrapped into a try-catch block * followup to #12371 Signed-off-by: Morris Jobke <[email protected]>
* fixes #9305 by not being prone to the race condition in insertIfNotExists * fixes #6899 by not using a query that can result in a deadlock * replaces the insertIfNotExists call with an insert which is wrapped into a try-catch block * followup to #12371 Signed-off-by: Morris Jobke <[email protected]>
I am getting this error under 15.0.7 when I share a link, or disable the sharing of the link. I am using linux, postgresql 10.8 and apache 2.4.39. I did not get this in 13.0.5 but I got it in 14.0.12. I am using gentoo. How would I use redis to get around this? |
I can reproduce this every time, so its not a race condition, or at least not that I could figure out. |
@covici Mind to open a new ticket about this and link to this one here? |
I had the same problem in production today, I just restarted redis container. |
Hit this problem during upgrade docker container from 23-24.... now stuck on update screen |
Steps to reproduce
However, the problem does not always occur! It seems that it depends on actual load or something.
Expected behaviour
The details sidebar should slide out and user should be able to share the folder.
Actual behaviour
The details sidebar slides out, but freeze with spinners spinning forever. Nextcloud logs exception:
When user reloads the page and try it again, then it suddenly works.
Please examine Nextcloud, web server and browser logs below.
Server configuration
Operating system: Linux
Web server: nginx
Database: PostgreSQL 9.6
PHP version: 7.1.16
Nextcloud version: 12.0.6
Updated from an older Nextcloud/ownCloud or fresh install: updates
Where did you install Nextcloud from: Alpine Linux package
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP
LDAP configuration (delete this part if not used)
LDAP config
Client configuration
Browser: various (Firefox, Safari, Chrome, …)
Operating system: various (Linux, macOS, Windows)
Logs
Web server error log
Web server error log
The first try to open Details sidebar (unsuccessful):
The second try to open Details sidebar (successful):
Nextcloud log (data/nextcloud.log)
Nextcloud log
Browser log
Browser log
The first XHR request sent after click on share button:
The second XHR request sent after click on share button:
After reload, the first request for
reshares=true
looks the same.The second XHR request sent after reload and click on share button again:
The text was updated successfully, but these errors were encountered: