Recover Windows and Plan 9 locks after process crash #15

Closed
opened 2026-09-28 18:41:03 +00:00 by mona · 0 comments

On Windows and Plan 9, locking is implemented by creating <lock>.held with O_EXCL and removing it only from the normal release callback. A force-kill or machine crash leaves the marker behind; future commands report lock busy until an operator removes it manually. The acquisition timeout only waits and returns an error; it cannot distinguish stale markers.

Relevant code: internal/lock/lock_create.go:16-40; busy handling is in internal/lock/lock.go:40-56.

Use a process-lifetime kernel lock where available, or introduce a race-safe stale-lock protocol that verifies owner identity before recovery. Do not automatically delete a marker based only on age or risk concurrent writers corrupting state.

Acceptance: platform-specific tests or documented platform CI exercise normal contention, process termination while holding the lock, and safe subsequent acquisition without allowing two simultaneous owners.

On Windows and Plan 9, locking is implemented by creating `<lock>.held` with `O_EXCL` and removing it only from the normal release callback. A force-kill or machine crash leaves the marker behind; future commands report lock busy until an operator removes it manually. The acquisition timeout only waits and returns an error; it cannot distinguish stale markers. Relevant code: `internal/lock/lock_create.go:16-40`; busy handling is in `internal/lock/lock.go:40-56`. Use a process-lifetime kernel lock where available, or introduce a race-safe stale-lock protocol that verifies owner identity before recovery. Do not automatically delete a marker based only on age or risk concurrent writers corrupting state. Acceptance: platform-specific tests or documented platform CI exercise normal contention, process termination while holding the lock, and safe subsequent acquisition without allowing two simultaneous owners.
mona Bot added the Kind/Bug
Priority
Medium
3
labels 2026-09-28 18:41:03 +00:00
kruno closed this issue 2026-10-08 20:40:47 +00:00
Sign in to join this conversation.