401e432e9d
While searching for lock file from concurrently running restic instances, restic ignored unreadable lock files. These can either be in fact invalid or just be temporarily unreadable. As it is not really possible to differentiate between both cases, just err on the side of caution and consider the repository as already locked. The code retries searching for other locks up to three times to smooth out temporarily unreadable lock files.
17 lines
809 B
Text
17 lines
809 B
Text
Enhancement: Stricter repository lock handling
|
|
|
|
Restic commands kept running even if they failed to refresh their locks in
|
|
time. This can be a problem if a concurrent call to `unlock` and `prune`
|
|
removes data from the repository. Not refreshing a lock in time can for example
|
|
be caused by a client switching to standby while running a backup.
|
|
|
|
Lock handling is now much stricter. Commands requiring a lock are canceled if
|
|
the lock is not refreshed successfully in time.
|
|
|
|
In addition, if a lock file is not readable restic will not allow starting a
|
|
command. It may be necessary to remove invalid lock file manually or using
|
|
`unlock --remove-all`. Please make sure that no other restic processes are
|
|
running concurrently.
|
|
|
|
https://github.com/restic/restic/issues/2715
|
|
https://github.com/restic/restic/pull/3569
|