Improve approach to waiting for Multipass start

Metadata

Project: craft-providers
Number: #796
Type: issue
State: open
Author: bepri
Labels: Type: Enhancement Status: Triaged
Created: 2025-08-12 05:26 PM UTC
Updated: 2025-09-17 08:54 PM UTC
Closed: —

Current evaluation

Enhancement: replace hardcoded 20s sleep after Multipass install with polling until multipassd is ready. TODO still in installer.py, triaged, but may be blocked by upstream canonical/multipass#1995.

Suggested action: keep open

Reason: Maintainer-authored enhancement carrying the Status: Triaged label, and the code confirms it is still open: installer.py retains `time.sleep(20)` with the comment '# We need a better way to detect this: .../issues/796', plus a second 20s sleep in _install_darwin(), and git log shows no commit removing them. The remedy is well-scoped and mostly pre-existing — Multipass.wait_until_ready() (multipass.py:460) already polls `multipass version` with RETRY_WAIT, matching @lengau's suggested 'iterative run of multipass list' approach; the residual work is making version() tolerate non-zero exits. Impact is moderate rather than severe (a first-install-only delay and flakiness, as @lengau notes it 'should only happen once per machine'), and the open design dependency on canonical/multipass#1995 keeps it from being fully turnkey.

Evaluated by: mr-cal-bot

Impact: 45 Quick Win: 24 Complexity: 30 Confidence: 82 Actionability: 75

Issue body

### What needs to get done Multipass needs time after being installed for `multipassd` to start. Without a delay, errors could happen on launch: `Remote "" is unknown or unreachable.` Current guidance is to sleep 20 seconds after install, but we should have a more reliable and timely approach. See: https://github.com/canonical/multipass/issues/1995 ### Why it needs to get done This was converted from a [TODO comment](https://github.com/canonical/craft-providers/blob/659de5cd6aff11da7c0b2c1d2964ba9f6524e7cf/craft_providers/multipass/installer.py#L50)

Evaluation history

Date	Model	Scores	Action	Summary
2026-10-02 08:24 PM UTC	stealth/space-bunny-alpha	Impact: 45 Quick Win: 24 Complexity: 30 Confidence: 82 Actionability: 75	keep open	Enhancement: replace hardcoded 20s sleep after Multipass install with polling until multipassd is ready. TODO still in installer.py, triaged, but may be blocked by upstream canonical/multipass#1995.
2026-09-24 09:15 PM UTC	stealth/space-bunny-alpha	Impact: 45 Quick Win: 23 Complexity: 33 Confidence: 93 Actionability: 76	keep open	Multipass installation still has fixed 20-second waits before daemon-dependent commands. This triaged enhancement proposes readiness polling but remains unimplemented.
2026-09-05 12:32 PM UTC	qwen3.6-35b-a3b-mtp-q6	Impact: 60 Quick Win: 42 Staleness: 75 Complexity: 30 Confidence: 70 Support Request: 10	keep open	Enhancement to replace hardcoded 20-second sleep with reliable polling for Multipass daemon startup after installation. Triaged but inactive for over a year.
2026-07-22 02:47 PM UTC	qwen/qwen3.6-35b-a3b	Staleness: 85 Complexity: 20 Confidence: 80 Support Request: 5	keep open	Enhancement to replace hardcoded 20-second sleep with a reliable polling mechanism for Multipass daemon startup. Triaged by maintainers, currently inactive for over a year.
2026-07-13 04:11 AM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 75 Complexity: 20 Confidence: 70 Support Request: 0	keep open	Enhancement to replace a hardcoded 20-second sleep with a reliable polling mechanism for Multipass daemon startup. Triaged but inactive for ~10 months.

Update history

No update history recorded yet.

Related work

Blocked By: multipass#1995 (confidence 75%)
Linked in the issue body as the upstream problem ('See: canonical/multipass/issues/1995'); @lengau noted 'We might be blocked by that issue', which is why the approach is still open.

Related issues

No related issues found above the similarity threshold.