LEARN. PRACTICE. GROW.The pathname is not the open object
The final concurrency exercise keeps a worker holding its lock and removes only the name of its private lock file. A new worker opens the same pathname, now creating another object, and acquires a second lock. The script confirms the first remains alive and the inodes differ. This behavior is why age-based cleanup should not be recommended as general recovery. File age or existence does not prove the owner died, and acquisition on the recreated object does not remove the earlier lock. The archived Apple manual explains the relationship between removing a name and open references; the lab supplies the concrete observation. All removal occurred on owned disposable resources without touching existing services.
Comparing and replacing are separate steps
The worker reads state, compares expectedRevision and, if the rule allows, writes a candidate and calls os.replace. Successful local replacement does not turn the earlier read and write into an indivisible conditional operation. Between those steps, a writer ignoring the protocol can modify state. The lab does not force that specific race or present it as an observed failure; it shows an outside writer before the read and a later blind write. That blind write replaces outside-protocol with blind-overwrite at revision 11. For a real target, choose and exercise a mechanism protecting the condition and mutation at the required scope. Additional reads may detect some differences but do not by themselves eliminate the boundary between checking and using.
Termination releases resources, not history
The script uses SIGTERM only on a child it created and whose identity it knows. It awaits exit, observes the negative code and starts another owner, which acquires the lock. State remains at revision 11: the written value was not rolled back. This separates three questions in an APS change: who now holds the resource, what state remains applied and what work may continue in other components. The lab launches no remote operations, so it establishes neither remote cancellation nor absence of pending effects. In a real procedure, do not replace that analysis with a duration-based kill. Define authority, owner identification, effect observation, stopping conditions and criteria for resuming or reconciling work.
Accept the mechanism and RUN capability
The proposed workshop asks APS, supplier and RUN to explain contention, rejected revision, the outside writer and the two lock objects in English. Participants must present a window decision and recovery with owners and observable criteria. The guide exists but has not been performed by a human group. The thirteen local groups passed twice; they do not validate remote filesystems, coordination across hosts, fencing or permissions. Retain those gaps in technical acceptance. In subsequent review, distinguish actions: covering every writer, preventing destructive cleanup of the coordination object, retaining a current plan and rehearsing resumption are different outcomes. Each action needs an owner, completion evidence and verification of its target gap; installing an alert does not replace those controls.
python3 content/labs/change-coordination/run.py --output /tmp/dr-change-lock-recovery.json
# Compare ownerExitReleasesLock and recreatedPathSplitsLockIdentity.
# Never apply the deliberate unlink experiment to an existing service.Deleting and recreating the private pathname permits two owners on distinct inodes; ending an owner releases the lock but retains revision 11.
Common pitfalls
Deleting.lock files by age, confusing os.replace with an atomic conditional comparison or assuming process termination undoes its effects.
Related topics: Nonparticipating writers · Handover and corrective actions
Preserve mechanism identity and verify effective state; local release, service recovery and reconciliation require their own evidence.
Reference: Postmortem Culture: Learning from Failure · BigSavant Change Management 2026.1; independent technical curriculum