Skip to content

uv-manager 0.6.1

Latest

Choose a tag to compare

@glentner glentner released this 08 Sep 02:01
· 17 commits to main since this release
0.6.1
634caaa

Fixed

A rank robbed of its fresh provisioning lock now retakes it instead of dying.

uvm_acquire_lock wins mkdir, then records ownership with a write that 0.6.0 made fatal on any
failure. That fatality is correct for a filesystem fault — a holder that cannot prove ownership leaks
its lock for a full stale window — but the redirect has two failure modes and 0.6.0 treated them
alike. A rank whose fresh lock directory was removed by a losing stale-breaker hit the same die and
exited 1 with empty stdout, so VER=$(uv --version) on a cold node came back empty and true.

The owner write now sits inside the acquire loop and the lock directory decides what happened. A
directory still standing is a genuine fault and still dies, carrying the errno the shell's own
diagnostic names. A directory already gone means this rank was robbed, and it retakes the lock under a
literal bound of three that never resets, adding no time to the existing UVM_LOCK_TIMEOUT accounting
and printing nothing on a successful retake.

Measured against 0.6.0 on an identical harness — a planted dead-holder lock, 64 ranks per round:

ranks failures
0.6.0 768 1
0.6.1 5760 0

Branch instrumentation over 1920 of those ranks caught three real robberies, all three retaken, none
routed to the fatal branch. The absent, waited and broke counters that bound the surrounding
wait loop are byte-identical to 0.6.0 on message, exit code, note count and timing.

Known residual. The retake decides between a lost race and a filesystem fault by testing whether
the lock directory is still standing, because a failed redirect leaves the shell no errno a branch can
read. A rank winning mkdir in the gap between the failed write and that test would still be
misclassified. The window is a single fork-free builtin, and 5760 ranks of the regime that produces
robberies found none of it, so this is narrower than what 0.6.0 ships rather than new.

Upgrading

No configuration change. No new environment variable, no new subcommand, and the provisioning
discipline is still mkdir. Sites deploying by git clone of a tag should re-clone 0.6.1; sites
tracking a moving main pick it up on their next pull. The Lmod modulefile derives its prefix from
myModuleVersion() and needs no edit, though a site that deploys per-version module files still has
to add one.

Also in this tag

34 [harness] commits to .agents/, the spec-driven factory this repository is developed with. They
change nothing a site deploys. The full design record for the fix is retained under
spec/lock-acquire-retake/.