Command suggestion: waitready

[kyrofa]

In tests for the snapcraft CLI, we install multipass and then run snapcraft builds. There's a bit of a race condition here where if multipass isn't completely fired up by the time the build starts, snapcraft errors out because multipass can't reach its daemon. LXD solved this issue by introducing a waitready command that we have utilized in our tests. Can we get similar functionality in multipass?

[sswastik02]

Hi @Saviq, I was wondering if this is still something the we desire. If so, I'd be happy to contribute and work on it.

[sharder996]

Hi @sswastik02,

Thank you for your interest in Multipass! We always welcome contributions from the community.

Yes, something like this has been requested multiple times by other users of Multipass. What is envisioned by the team is a CLI command; multipass wait-ready, that would only return once the daemon is accessible. Subsequently, a --timeout option would also be necessary in order to prevent the command from hanging forever.

Or, if you have any other ideas, please feel free to use this thread to discuss!

[sswastik02]

Hi @sharder996, Thanks for your response, I agree there should be a --timeout flag, however I also think we should also allow the command to hang forever if the user desires so, the user could do this by not specifying the same flag. What do you think ?

[sharder996]

Sure, the command could wait forever if no timeout is specified.

[ItsukiYoshida]

Hi @sswastik02 .

I was thinking of doing #3723, and I heard that this one might be more inclusive. Are you currently working on this issue? If you’re not planning to tackle it in the near future, I’d be happy to take a look at it—what do you think?

[sswastik02]

Hi @ItsukiYoshida,

Please feel free to contribute to this PR! I won’t be working on it in the near future.

[ricab]

Hey @ItsukiYoshida, @sswastik02, did either of you make progress on this? Patches would still be welcome!

[rluna319]

Hi @ricab,

Are patches for this issue and #3723 still welcome? If so, I would like to see if I can implement the multipass wait-ready with an optional --timeout flag.

[ricab]

Hi @rluna319, yes very much so! I don't think we got any PRs for this yet. Thanks for your interest!

[rluna319]

@ricab

I believe I have a solution to this issue and #3723 implemented. Before I cleanup and submit a PR, I would just like to verify my understanding.

Shortly after installing/building multipass, or more specifically, shortly after the daemon starts up, either the multipass client is not able to connect to it or the daemon can't reach the image servers yet. This results in errors like:

$ (sudo ./multipassd &) && ./multipass launch

launch failed: cannot connect to the multipass socket


$ (sudo ./multipassd &) && sleep 1s && ./multipass launch

launch failed: Remote "" is unknown or unreachable.

or using snap:

$ sudo snap start multipass && multipass launch

Started.

launch failed: cannot connect to the multipass socket


$ sudo snap start multipass && sleep 0.5s && multipass launch

Started.

launch failed: Remote "" is unknown or unreachable.

Its hard to reliably get it to reproduce the exact error in #3723, "launch failed: Remote "release" is unknown or unreachable. If image mirror is enabled, please confirm it is valid." I believe it has a lot to do with how fast your machine is or what it already has cached and at what point it errors out.

But to my understanding its all the same, the daemon is not fully initialized and able to connect to the image servers.

---

The wait-ready command polls the daemon till its available and able to connect to it, then once the daemon receives the wait-ready command, it checks for connection to the image servers until the --timeout specified is reached, or some other connection error occurs.

My approach reuses the wait_update_manifests_all_and_optionally_applied_force() method from the mp::Daemon class. I also reused the multipass::cmd::parse_timeout() to implement the --timeout option which I believe was intended for more instance related commands.

I could create more custom lightweight methods but i figured it might be better to just reuse as much of the existing code as possible to minimize the need for additional tests. I have NOT implemented any tests for the new wait_ready.cpp I made as I'm not sure if that's a requirement for the PR.

---

Build from source example with debug logging:

$(sudo ./multipassd &) && ./multipass wait-ready -vvv --timeout 10 && ./multipass launch
Multipass daemon is not ready yet. Retrying...
Multipass daemon is not ready yet. Retrying...
[2025-06-03T16:26:49.434] [debug] [daemon] Checking connection to image servers...
[2025-06-03T16:26:49.639] [debug] [async task] fetch manifest from the internet
[2025-06-03T16:26:52.153] [debug] [daemon] Successfully connected to image servers.
Retrieving image: 4%

Using locally built snap:

$ sudo snap start multipass && multipass wait-ready -vvv --timeout 10 && multipass launch
Started.
Multipass daemon is not ready yet. Retrying...
Multipass daemon is not ready yet. Retrying...
Multipass daemon is not ready yet. Retrying...
[2025-06-03T16:31:26.849] [debug] [daemon] Checking connection to image servers...
[2025-06-03T16:31:26.850] [debug] [async task] fetch manifest from the internet
[2025-06-03T16:31:29.331] [debug] [daemon] Successfully connected to image servers.
Retrieving image: 3%

The "Multipass daemon is not ready yet. Retrying..." is my own debugging print out. I will remove that (or I can leave that if desired).

Using -h:

$ multipass wait-ready -h
Usage: multipass wait-ready [options]
Wait for the Multipass daemon to be ready.
This command will block until the daemon is ready to accept requests.
It can be used to ensure that the daemon is running before executing other commands.
If a timeout is specified, it will wait for that duration before exiting with an error if the daemon is not ready.

Options:
  -h, --help           Displays help on commandline options
  -v, --verbose        Increase logging verbosity. Repeat the 'v' in the short
                       option for more detail. Maximum verbosity is obtained
                       with 4 (or more) v's, i.e. -vvvv.
  --timeout <timeout>  Maximum time, in seconds, to wait for the command to
                       complete. Note that some background operations may
                       continue beyond that. By default, instance startup and
                       initialization is limited to 5 minutes each.

---

Is this good for a PR? I'm assuming anything else I need to do will be handled through that process.

I know I must sign a form, other than that I didn't see much else of any other contributing guidelines.

If I've missed something please let me know.

[ricab]

Hi @rluna319! Your understanding regarding the error messages is correct. In particular, remote unknown or unreachable occurs at that point because Qt's networking infrastructure isn't ready yet and a successful wait-ready command should return only once neither of those errors apply.

What you describe looks pretty good! We need to review the code and details like the functions you mention, but I don't see any obvious obstacle. As for unit tests: yes, we'd need them before merging, but it would be perfectly reasonable to put a PR up for review before that; probably even wise, to confirm things before spending time testing them. Even with no tests, your PR would still be useful: it would allow us to pick up and refine at a later date. Even better if you decide to implement tests and take it to the finish line 🙂

One thing I would probably request tweaks on is the "retrying" message. Other commands use a spinner to communicate what is happening to the user and I think that would be the most suitable here. But we can leave those details for review.

Is this good for a PR?

Yep, it very much looks like it!

I didn't see much else of any other contributing guidelines.

You're right. We're in the process of drafting them and we hope to have them soon, but not quite there yet. So yes, we can discuss any other matter during review.

Just so you know what to expect, we are currently preparing a release and there are a number of other PRs waiting for review, so it may take a little while until we can get to this one. That said, I am quite excited to see your post; what you show there looks pretty good and we'd love to get it in the following release. Thanks again for your involvement!

[xmkg]

wait-ready is now a thing thanks to @rluna319! It should be available in the next feature release.