pub fn lock_setup() -> Result<SetupLock>Expand description
Take the lock that serialises a whole proxy setup run.
It has to span the entire transaction, not just one step. The CLI reads the
records, builds a plan from them, writes the new record, applies the plan
and, on undo, clears the record. Locking only the apply would still let a
second run read the same records, build a plan against a state the first run
is about to change, and then apply it — including splicing a block into
/etc/pf.conf or a resolver drop-in from a stale pre-image, so one run’s
edit is silently dropped while both report success.
A lock that cannot be taken is an error rather than a warning to run on
through. Every step past this point edits shared system state — a resolver
file, a firewall rule, the trust store — and this repository’s rule is that
the state file is always locked. Applying those edits unserialised because
the lock was unavailable is the one outcome worse than not applying them.
The record file is the lock’s name, not the file that gets locked:
xx::fslock flocks a file of its own under the temporary directory, keyed
on a hash of this path. So clear_record unlinking the record after a
successful undo does not drop or orphan the lock, and a run waiting on it
still holds the same one.