From 5b3d82f9bcb0170aa1fcb8695f101dbb4db898b5 Mon Sep 17 00:00:00 2001 From: Paul Holzinger Date: Wed, 29 Nov 2023 17:03:28 +0100 Subject: [PATCH] sqlite: set busy timeout to 100s Only one process can write to the sqlite db at the same time, if another process tries to use it at that time it fails and a database is locked error is returned. If this happens sqlite should keep retrying until it can write. To do that we can just set the _busy_timeout option. A 100s timeout should be enough even on slower systems but not to much in case there is a deadlock so it still returns in a reasonable time. [NO NEW TESTS NEEDED] I think we strongly need to consider some form of parallel stress testing to catch bugs like this. Fixes #20809 Signed-off-by: Paul Holzinger --- libpod/sqlite_state.go | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libpod/sqlite_state.go b/libpod/sqlite_state.go index e3bd5022fe..2dc1bb384f 100644 --- a/libpod/sqlite_state.go +++ b/libpod/sqlite_state.go @@ -40,13 +40,17 @@ const ( sqliteOptionForeignKeys = "&_foreign_keys=1" // Make sure that transactions happen exclusively. sqliteOptionTXLock = "&_txlock=exclusive" + // Make sure busy timeout is set to high value to keep retying when the db is locked. + // Timeout is in ms, so set it to 100s to have enough time to retry the operations. + sqliteOptionBusyTimeout = "&_busy_timeout=100000" // Assembled sqlite options used when opening the database. sqliteOptions = "db.sql?" + sqliteOptionLocation + sqliteOptionSynchronous + sqliteOptionForeignKeys + - sqliteOptionTXLock + sqliteOptionTXLock + + sqliteOptionBusyTimeout ) // NewSqliteState creates a new SQLite-backed state database.