drill/multiuser.sh — the drill's last-resort recovery still force-stops through raw incus, and #236 makes that expressible as box down --force: migrate it, or say in the file why it stays raw?

[dan-claude-bot]

Raised by @cndgrr on #236 at 2026-08-29T13:16:08Z, and brought here by triage rather than minted as an issue, because it has an open question in it and TRIAGE.md does not let a spec carry one.

The fact

#236 gives box down a --force that maps to incus stop --force, with the user.box=1 boundary enforced on the force path. Its whole premise is that box incus <box> -- stop --force is an escape hatch being used as a feature — an unguarded incus call wearing box's name.

drill/multiuser.sh has one such call. Measured on main at 7d9db3c, inside bounded_admin_down():

timeout -k 5 60 box down all >"$capture" 2>&1; rc=$?
...                       # only if rc is 124 or 137 — the timeout fired
ops="$(timeout -k 2 10 incus operation list --format csv 2>&1 || true)"
guest="$(timeout -k 2 10 incus exec "$b" -- systemctl list-jobs --no-legend 2>&1 || true)"
...                       # the three diagnostic prints
timeout -k 5 30 incus stop "$b" --force >/dev/null 2>&1 || true

After #236 merges that last line is expressible as box down "$b" --force. The question is whether it should be.

The question, stated as the two readings

Reading A — migrate it. It is the same shape #236 exists to close. A drill that rehearses the product should not reach past the product, and leaving it raw means the repository ships a --force verb while its own drill demonstrates the hatch. crew#588 is migrating for exactly this reason.

Reading B — leave it raw, and say why in a comment. This is not an ordinary call site. It is reached only when box down all has already blown a 60-second timeout — the recovery path for a box down that did not return. Making it call box down --force makes the recovery depend on the verb whose failure it is recovering from: if down is wedged for a reason that is box's rather than the guest's, the escape is wedged with it. On this reading the raw call is the point, and it wants a comment saying so, not a migration.

There is a third position worth naming: B for this call site, A as the rule — i.e. the drill's last-resort path stays raw and documented, and any other raw incus call in the repo is a defect.

What is already true, so the discussion does not re-derive it

• bin/box — box down is incus stop with no force, so a wedged box cannot be stopped at all: --force, and the escape hatch stops being the answer #236 does not fix this and should not. It is a consumer migration, not that issue's deliverable, and it was correctly left alone in PR #242.
• test/cli.sh pins the current spelling. Whatever this settles is a two-file change, not a one-line one.
• Nothing here is in the 0.10.0 window. #182 is closing on the cut (#222); this is post-window work whichever way it goes.
• It is not the only raw forceful incus stop under drill/, and the other two are a different category. drill/drill.sh:1633 and :1737 each run incus stop -f on cbprobe and tpl — but those lines exist to set up an assertion about incus itself (that incus copy preserves user.* keys, and that a live-instance clone reads back the daemon's own config). They rehearse incus deliberately. bounded_admin_down() is the only one recovering from box's verb, which is why it is the one this question is about. If the answer is Reading A, say whether it reaches those two as well; triage's view is that it does not.

What triage needs to mint

One sentence answering A or B, and if B, whether the rule in the third position holds for the rest of the repo. With that, this is an ordinary small issue; without it, minting one would just move the question onto a builder.

[dan-claude-bot]

Settled: Reading B — the call stays raw, the file says why, and no repository-wide rule is declared. Minted as #246; closing this.

The answer was already given, on the wrong thread

This discussion asked for "one sentence answering A or B" and has sat with zero comments since 13:28:55Z. The sentence exists. @cndgrr wrote it on
#236 at 14:42:28Z — 74 minutes after this thread opened, and on the thread this one was extracted from:

On drill/multiuser.sh:160 → discussion #243. Accepted, and your reason is better than mine: I stopped at scope discipline, and the real objection is that bounded_admin_down() is diagnosing a box down that did not return, so rewriting it to box down … --force would make the recovery path depend on the verb whose failure it exists to survive.

That is Reading B, from the builder who raised the objection in the first place, agreeing with the triage analysis in this body. Triage did not carry it here, and the 17:3x board snapshot then listed this thread as still-unanswered work on @danmt. It was not: it was answered work nobody had written down. Recording the miss rather than quietly fixing it — a discussion whose answer lives on another thread reads, to every scan, exactly like a discussion nobody has answered.

What is decided

B for this call site. bounded_admin_down() is reached only when timeout -k 5 60 box down all has returned 124 or 137; every other status returns early with box's own answer. The raw stop is the recovery path for a box down that did not come back, and routing it through box down --force would make the escape depend on the verb whose failure it exists to survive. The comment above the function explains the bound and says force is "only as recovery" — it was written before the verb existed, so it cannot say why the verb is not used, and after #236 the raw line reads as an oversight to anyone grepping for the escape hatch. That is the whole of #246.

The third position — "B here, A as the rule for the rest of the repo" — is not adopted, because the corpus does not support a rule. Measured at 50b4235, not recalled: drill/ contains exactly three forceful incus stop calls.

site	what it is
drill/multiuser.sh:159	the recovery this thread is about — the only one recovering from box's verb
drill/drill.sh:1633	incus stop -f cbprobe, setting up probe A9 — "incus copy preserves user.* keys"
drill/drill.sh:1737	incus stop -f tpl, before the live-instance clone that reads sizing back off the daemon

The two in drill.sh exist to set up assertions about incus itself, so routing them through box would make a claim about the daemon depend on the tool under test. This body's own guess — "triage's view is that it does not [reach those two]" — holds on measurement. With one site in the class and two deliberate exclusions, there is no rule to write; a repository-wide policy over a corpus of one is a sentence pretending to be a constraint. If a fourth site ever appears, it is a fresh question with an actual corpus behind it.

One thing this body got wrong, corrected

test/cli.sh pins the current spelling. Whatever this settles is a two-file change, not a one-line one.

It is a two-file change, for the opposite reason. Under B the existing pin — "multiuser: (p) force-stops only as post-failure recovery", which greps incus stop "$b" --force — needs no edit at all; it is what keeps the decision from being silently migrated away later, so it is load-bearing exactly as written. The second file is a new check pinning the rationale, because nothing today stops a tidy-up that keeps the call and deletes the comment. Both files move, neither of them the way the sentence implied.

The line numbers in this body were re-verified rather than assumed: 1633 and 1737 are still correct at 50b4235, and multiuser.sh:159 is unchanged by #236's merge.

Where it went, and what it is not

#246 — documentation, scope:drill, blocked, precedence ordinary. It is a non-member of the 0.10.0 window, declaring Blocked by #182, #241, and it is recorded on #182's membership record in the same tick as the mint. The non-membership call is triage's, and its reason is sharper than "post-window work": drill/multiuser.sh is one of the scripts @danmt's 0.10.0 drill session runs. Editing it inside the window moves the rehearsal under the cut it is meant to witness, for a change that fixes no defect and alters no behaviour. The second edge is a test/cli.sh collision with #241, which is claimed — that issue is not retro-blocked and no label on it moved.

@danmt — this is triage's decision, not yours to make, and it is yours to overturn. It comes off your list; #246 is where to argue with it, and nothing about it touches 0.10.0.

— triage 2026-08-29 17:4x