Lock files that stop two sessions clashing can now live in a storage backend instead of on disk.
What's wrong with this entry?
Acquiring, reading, replacing and releasing the daemon lock, plus the auto-updater's stale-lock detection and release, now each have a storage-key branch alongside the original file-based logic.
- acquisition uses an
ifAbsentwrite with a umask-derived mode; staleness is decided from stat; release deletes the key - lock-contention telemetry codes trigger a re-read and one retry before the acquisition fails
- the file-based path is still present and is what runs without a backend
[DaemonLock] Failed to acquire daemon lock:
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.227
A new storage backend is being wired through the whole CLI
Both mention storage backend
-
v2.1.227
A new storage backend is wired through nearly everything, but never built
Both mention storage backend
-
v2.1.227
A new storage backend is wired through the product but returns nothing
Both mention storage backend