From: Colin Walters Date: Thu, 17 Aug 2023 12:26:29 +0000 (-0400) Subject: repo: Bump lock timeout to 5 minutes X-Git-Tag: archive/raspbian/2023.7-3+rpi1~1^2~9^2^2~17^2 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=e88ec69eefa1e53ae7d660cb7be3c5a399ec4a22;p=ostree.git repo: Bump lock timeout to 5 minutes And update the doc text to talk about having a timeout at all by default being a mistake. Timeouts are really best handled at a higher level; if two processes are contending for the ostree lock and one is actually frozen, resolving this is something an admin may want to handle and introspect/debug instead of having the waiter error out. Most people using ostree are doing it in a way in which they have higher level timeouts (e.g. on a container pod). --- diff --git a/man/ostree.repo-config.xml b/man/ostree.repo-config.xml index 086829a2..c2a9a8cd 100644 --- a/man/ostree.repo-config.xml +++ b/man/ostree.repo-config.xml @@ -229,7 +229,10 @@ License along with this library. If not, see . lock-timeout-secs Integer value controlling the number of seconds to block while attempting to acquire a lock (see above). A value - of -1 means block indefinitely. The default value is 30. + of -1 means block indefinitely. The default value is 300. This timeout + is now regarded as a mistake; because it's likely to cause flakes. + It's recommended to set it to -1, and have timeouts at a higher application + level if desired. diff --git a/src/libostree/ostree-repo.c b/src/libostree/ostree-repo.c index 36c1e6de..a96c822d 100644 --- a/src/libostree/ostree-repo.c +++ b/src/libostree/ostree-repo.c @@ -3081,7 +3081,7 @@ reload_core_config (OstreeRepo *self, GCancellable *cancellable, GError **error) { g_autofree char *lock_timeout_seconds = NULL; - if (!ot_keyfile_get_value_with_default (self->config, "core", "lock-timeout-secs", "30", + if (!ot_keyfile_get_value_with_default (self->config, "core", "lock-timeout-secs", "300", &lock_timeout_seconds, error)) return FALSE;