Intermittent: 'box new' hangs before the instance exists — incus launch client wedges with no server-side operation #93

New issue

Closed

opened 2026-07-19 12:11:12 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-19 12:11:12 +00:00

(Migrated from github.com)

What happened

Two of ~8 mints on this host (Debian 13, Incus 6.x, nested VM with /dev/kvm, images fully cached) wedged the same way:

box new --name conv-grok --template grok — the child incus launch ran for 56 minutes; killed by hand.
box new --name conv-staging --template staging — same shape; killed by a 540s wrapper timeout.

In both cases, while the client hung:

incus operation list → empty (no server-side operation at all)
incus list → the instance does not exist
daemon journal quiet; no OOM (dmesg clean, >3 GiB available); disk fine
the image needed (images:debian/13/cloud, VM variant) already in the local store
images: remote answered a fresh incus image list images: in ~2s

An immediate retry of the identical command succeeded in ~2-3 minutes, both times. The 85/0 drill run earlier the same day minted ~6 boxes serially through one process with no wedge; both wedges happened on mints launched from fresh shells (sg incus-admin -c … incus exec …; … box new … compound invocations).

Why file it against box

Even if the wedge is an Incus client/stream bug, box new currently inherits it as an indefinite silent hang: no progress line distinguishes "cold mint, working" from "wedged before the create was even accepted". RUNS.md documents stall diagnosis for the drill; the tool itself could:

Narrate the launch phase (launching instance… before the first dot), so a wedge is visible in one glance.
Time-box the incus launch call (generous — cold VM mints are minutes, not an hour) and fail loudly with the retry hint, since the observed failure retries clean.

Happy to close as external if this reproduces as a bare-incus bug — but box is where an operator meets it.

🤖 Filed from the release-drill session.

Observed twice during the 2026-07-19 release drill; filing with evidence even though the root cause is not pinned down — a mint that hangs forever with no narration is a finding regardless of whose bug it turns out to be. ## What happened Two of ~8 mints on this host (Debian 13, Incus 6.x, nested VM with /dev/kvm, images fully cached) wedged the same way: - `box new --name conv-grok --template grok` — the child `incus launch` ran for **56 minutes**; killed by hand. - `box new --name conv-staging --template staging` — same shape; killed by a 540s wrapper timeout. In both cases, while the client hung: - `incus operation list` → **empty** (no server-side operation at all) - `incus list` → the instance does **not exist** - daemon journal quiet; no OOM (`dmesg` clean, >3 GiB available); disk fine - the image needed (`images:debian/13/cloud`, VM variant) already in the local store - `images:` remote answered a fresh `incus image list images:` in ~2s An **immediate retry of the identical command succeeded in ~2-3 minutes**, both times. The 85/0 drill run earlier the same day minted ~6 boxes serially through one process with no wedge; both wedges happened on mints launched from fresh shells (`sg incus-admin -c … incus exec …; … box new …` compound invocations). ## Why file it against box Even if the wedge is an Incus client/stream bug, `box new` currently inherits it as an **indefinite silent hang**: no progress line distinguishes "cold mint, working" from "wedged before the create was even accepted". RUNS.md documents stall diagnosis for the *drill*; the tool itself could: 1. Narrate the launch phase (`launching instance…` before the first dot), so a wedge is visible in one glance. 2. Time-box the `incus launch` call (generous — cold VM mints are minutes, not an hour) and fail loudly with the retry hint, since the observed failure retries clean. Happy to close as external if this reproduces as a bare-`incus` bug — but box is where an operator meets it. 🤖 Filed from the release-drill session.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/box#93

No description provided.