Multipass becomes unresponsive when purging multiple machines simultaneously

[morphis]

I was removing two machines from multipass today and it turned unresponsive when calling the purge command:

+ multipass delete ams0
+ multipass delete lxd0
+ multipass purge
purge failed: Socket closed
$ multipass purge
purge failed: Connect Failed
$ multipass ls
list failed: Connect Failed

After waiting a moment multipass was able to answer my requests again. It seems that multipass seems to hang on parallel requests quite a lot like a multipass delete <container name> will cause a parallel executed multipass ls to hang until the delete operation has finished.

To improve the user experience none of the multipass commands should hang or return a error message saying Connect Failed. If certain operations cannot be executed in parallel multipass should surface that with a proper error message.

[townsend2010]

@morphis,

Thanks for the report. Based on that, it actually seems like the daemon died and then was re-spawned by snapd. Anything in journalctl to shed light on what might have happened at that time?

[morphis]

@townsend2010 That is what I thought too but the multipassd daemon was alive and the last message shown in the journal output was

Aug 29 08:08:33 saturn multipassd[22278]: gRPC listening on unix:/run/multipass_socket

I've verified that once the daemon was reactive again it wasn't restarted in between.

It feels a bit like the RPC endpoint in multipassd is single-threaded or a lock is somewhere blocking requests to be processed in parallel.

[townsend2010]

This could possibly be a race between the previous not fully completed delete operation and the subsequent purge operation working on the same data in the internal DB. Will look further into it.

[townsend2010]

This should be fixed by the recent asynchronous work put into multipassd.