-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
sqlite: database is locked #17859
Comments
Here's one in
(there's another one in that same log, with Here's one in podman-remote |
Opened #17867 as an anticipated fix. |
The symptoms in containers#17859 indicate that setting the PRAGMAs in individual EXECs outside of a transaction can lead to concurrency issues and failures when the DB is locked. Hence set all PRAGMAs when opening the connection. Move them into individual constants to improve documentation and readability. Further make transactions exclusive as containers#17859 also mentions an error that the DB is locked during a transaction. [NO NEW TESTS NEEDED] - existing tests cover the code. Fixes: containers#17859 Signed-off-by: Valentin Rothberg <[email protected]>
Sorry:
In f36 root container, and this is in my #17831 PR which includes all sqlite fixes so far as of Monday. |
Another one, f37 rootless host (not container). |
`Ping()` requires the DB lock, so we had to move it into a transaction to fix containers#17859. Since we try to access the DB directly afterwards, I prefer to let that fail instead of paying the cost of a transaction which would lock the DB for _all_ processes. [NO NEW TESTS NEEDED] as it's a hard to reproduce race. Fixes: containers#17859 Signed-off-by: Valentin Rothberg <[email protected]>
Sorry. Seen in my no-flake-retries PR, f37 rootless, the usual symptom (in
This version of the CI run DOES NOT include the WAL diffs, it's just hammering at sqlite. Reopening, sorry. |
Cc: 🚑 @mheon |
According to an old upstream issue [1]: "If the first statement after BEGIN DEFERRED is a SELECT, then a read transaction is started. Subsequent write statements will upgrade the transaction to a write transaction if possible, or return SQLITE_BUSY." So let's move the first SELECT under the same transaction as the table initialization. [NO NEW TESTS NEEDED] as it's a hard to cause race. [1] mattn/go-sqlite3#274 (comment) Fixes: containers#17859 Signed-off-by: Valentin Rothberg <[email protected]>
Almost certainly related to #17858 but I will let someone else decide and possibly merge.
Unfortunately, this is also happening a lot in
cleanup
, where for long and horrible complicated reasons my flake logger cannot detect:https://api.cirrus-ci.com/v1/artifact/task/4709781731016704/html/int-podman-fedora-37-rootless-host-sqlite.log.html#t--netns--1
https://api.cirrus-ci.com/v1/artifact/task/6409078293921792/html/int-podman-fedora-37-rootless-host.log.html#t--Podman-start-after-signal-kill--1
The text was updated successfully, but these errors were encountered: