← Back to issue list

Multiprocess operations can lead to spinner deadlock

View original Github issue

Metadata

Project
craft-cli
Number
#172
Type
issue
State
open
Author
cmatsuoka
Labels
—
Created
Updated
Closed
—

Current evaluation

Maintainer-filed bug: craft-cli starts its _Spinner in a thread and acquires its lock on every message, so a forked child (e.g. craft-parts overlay chroot) deadlocks on a lock whose owner thread no longer exists. Still unfixed.

Suggested action: keep open

Reason: The defect is still present at HEAD: craft_cli/printer.py:240 supervise() does an unconditional `self.lock.acquire()/release()` against a threading.Lock owned by a `threading.Thread` (_Spinner, printer.py:169), and there is no `os.register_at_fork` or `os.getpid()` handling anywhere in the repo, so a forked overlay child can hang. A maintainer (cmatsuoka) authored the report and pointed at the craft-parts workaround, so the bug is valid and unresolved; craft-parts PR #535 only downgraded overlay logging from info to debug, which avoids the trigger rather than fixing the printer. Keep open, though scoring is tempered because 'To Reproduce' and 'Relevant log output' are both TODO — there is no reproducer or proposed fix design.

Evaluated by: mr-cal-bot

Impact: 55 Quick Win: 12 Complexity: 55 Confidence: 78 Actionability: 48

Issue body

### Bug Description There is a bad interaction between the way we perform overlay operations (a chroot in a multiprocess-created subprocess) and the way craft applications indicate progress on the cli (a spinner in a thread). The consequence of the bad interaction is that trying to write an info message to the terminal ends up deadlocking the main thread in the subprocess because the thread that could unblock it does not exist. See https://github.com/canonical/craft-parts/pull/535. ### To Reproduce TODO ### part yaml _No response_ ### Relevant log output ```shell TODO ```

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 55
Quick Win: 12
Complexity: 55
Confidence: 78
Actionability: 48
keep open Maintainer-filed bug: craft-cli starts its _Spinner in a thread and acquires its lock on every message, so a forked child (e.g. craft-parts overlay chroot) deadlocks on a lock whose owner thread no longer exists. Still unfixed.
qwen/qwen3.6-35b-a3b
Impact: 40
Quick Win: 12
Complexity: 50
Confidence: 70
Actionability: 60
needs triage Multiprocess overlay operations can deadlock craft-cli's spinner thread in subprocesses. Craft-parts PR #535 implemented a workaround by downgrading overlay logging from info to debug.
qwen/qwen3.8-27b
Impact: 45
Quick Win: 14
Staleness: 88
Complexity: 70
Confidence: 60
Support Request: 5
close stale Deadlock when a multiprocess overlay chroot subprocess writes an info message while the CLI spinner thread is active. Stub report, no labels or comments in 3 years. Referenced craft-parts PR #535 merged to mitigate by downgrading overlay logging to debug.
qwen/qwen3.6-35b-a3b
Staleness: 95
Complexity: 65
Confidence: 85
Support Request: 5
close stale Multiprocess overlay operations can deadlock the CLI progress spinner thread in a subprocess. Reported ~3 years ago with no reproduction steps, labels, or maintainer follow-up. Currently untriaged and inactive.
qwen3.6-35b-a3b-mtp-q6
Staleness: 95
Complexity: 75
Confidence: 85
Support Request: 5
needs triage Multiprocess overlay operations deadlock CLI spinner threads. Reported by a maintainer nearly three years ago with no reproduction steps, labels, or maintainer comments. Requires assessment to determine if referenced PRs resolved it or if it remains relevant.

Update history

No update history recorded yet.

Related work

  • Related To: canonical/craft-parts#535 (confidence 90%)

    Explicitly linked in the issue body; that PR downgraded overlay logging from info to debug as a workaround, not a fix in craft-cli.

Related issues

No related issues found above the similarity threshold.