`ls` does not return in `prime`'s home directory

[ikitayama]

Describe the bug In a VM running for a while, when I issue ls in my home directory it does not return.

Expected behavior lists directories and files.

Additional info

• OS: macOS latest
• Versions: multipass 1.9.2+mac multipassd 1.9.2+mac
• multipass info --all

Name:           primary
State:          Running
IPv4:           192.168.64.16
                172.17.0.1
Release:        Ubuntu 20.04.4 LTS
Image hash:     add2f33bf439 (Ubuntu 20.04 LTS)
Load:           0.10 0.17 0.08
Disk usage:     98.7G out of 116.1G
Memory usage:   315.3M out of 15.6G
Mounts:         /Users/itaru => Home
                    UID map: 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default, 501:default
                    GID map: 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default, 20:default
                /Users/itaru => /home/ubuntu/Home
                    UID map: 501:default
                    GID map: 20:default

Additional context Add any other context about the problem here.

[ikitayama]

I do always quit Multipass and restart primary.

[ikitayama]

Running vm for about an hour, this is reproducible.

[ikitayama]

By doing unmount, the system becomes again responsive. Any bugs/limitations on the mount subcommand in the latest release?

[townsend2010]

Hi @ikitayama!

Sorry for your issues with Multipass. On first inspection, the mounts you have defined don't seem correct. Could you tell me how you are defining additional mounts aside from the default primary Home mount?

Thank you!

[ikitayama]

@townsend2010 thanks for your reply. I forgot. And this afternoon multipass seemed to have deleted primary's image I've accumulated over the last couple of months and rebuilt it fresh. Is this expected to happen?

❯ multipass info --all
Name:           primary
State:          Stopped
IPv4:           --
Release:        --
Image hash:     0f1a20bcda28 (Ubuntu 20.04 LTS)
Load:           --
Disk usage:     --
Memory usage:   --
Mounts:         /Users/itaru => Home
                    UID map: 501:default
                    GID map: 20:default

[ikitayama]

I actually did upgrade to the latest release of Ubuntu and it consumed much of System Data on macOS.

[ikitayama]

Should I open up a new Issue?

[townsend2010]

Hi @ikitayama,

No, Multipass should never just delete an existing instance and rebuild it from fresh. Yes, please open a new issue and please provide any all logs.

Also, I'm not sure what you mean by upgrading to the latest release consumed much of System Data on macOS. Could you please explain what you mean here in some more detail?

Thank you!

[ikitayama]

Okay. I'll do that.

As of this writing, my primary instance is backed by 20.04.4 LTS, although I'd upgraded to as I remember 22.04. While I was using the former primary, macOS was reporting 600GB of System Data usage that resulted in non-writable satte as I have only 1 TB of storage.

[ikitayama]

This bites me again with the freshly created Multipass instance.

[ikitayama]

What info should I provide? Given this being a mount issue.

[townsend2010]

Hi @ikitayama,

Ok, sorry this keeps happening to you. I assume you mean you are still hitting the ls issue, correct?

Just so I understand this better, you are saying that you have the primary instance up and running and when you do ls in your home directory on your Mac and not in the primary instance, the ls command will hang. Is this correct?

Also, in order to help us more diagnose what may be happening, could you please answer the following questions?

• Are you using an Intel Mac or M1 Mac?
• If Intel Mac, could you please provide output of multipass get local.driver?
• Is your Mac suspending and resuming before this issue occurs?
• Are you running any processes inside the primary instance that may be causing high I/O load particularly in the mount itself?

That is all for now and we'll wait on your answers :slightly_smiling_face: Thank you!

[ikitayama]

Hello @townsend2010

Ok, sorry this keeps happening to you. I assume you mean you are still hitting the ls issue, correct?

Yes.

Just so I understand this better, you are saying that you have the primary instance up and running and when you do ls in your home directory on your Mac and not in the primary instance, the ls command will hang. Is this correct?

ls is executed in primary's home directory. Then prompt does not return in a reasoable manner.

Also, in order to help us more diagnose what may be happening, could you please answer the following questions?

• Are you using an Intel Mac or M1 Mac?

M1 Max.

• If Intel Mac, could you please provide output of multipass get local.driver?

N/A

• Is your Mac suspending and resuming before this issue occurs?

Yes. I close the lid and open without turning off M1.

• Are you running any processes inside the primary instance that may be causing high I/O load particularly in the mount itself?

Not in this case, never done that.

That is all for now and we'll wait on your answers 🙂 Thank you!

Thanks for taking a look!

[townsend2010]

Ok, I'm wondering if suspending and resuming the laptop is what is breaking the mounts here. I will investigate that avenue more.

[ikitayama]

If someone is already investigating the suspend resume issue, would you mind telling us the Issue number? Thanks!

[townsend2010]

Hi @ikitayama!

I have not tried to reproduce the issue yet, so I'm not even sure if my theory is true. In the meantime, if you do run into this issue again, could you see if you see any process running at ~100% (or greater) CPU time on your host and if so, please let us know which process it is.

That said, this would be the bug where we track this once we have time to investigate.

Thanks!

[ikitayama]

Sure I will!

[ikitayama]

The process is qemu-system-aarch64. After rebooting the primary instance I was able to issue ls in my $HOME directory in primary.

[townsend2010]

Ok, thank you. Is it possible to see which process inside the instance is taking all of the CPU time? Thanks again!

[ikitayama]

While the VM is busy on host, inside the VM, none of them is taking much CPU time.

[ikitayama]

When this happens, inside the VM nothing is taking CPU time.

[ikitayama]

Not sure related, but I was doing a Linux kernel build using the max number of CPUs (=8) which ended successfully.

[ikitayama]

I still see this often and the resolution is always to stop the VM.