podman machine on macOS becomes unresponsive after some time #20639

benoitf · 2023-11-09T09:16:36Z

Issue Description

My podman machine is not responding after some time.

CLI is not responding but podman machine ls says it's running

$ podman machine ls 

NAME                     VM TYPE     CREATED     LAST UP            CPUS        MEMORY      DISK SIZE
podman-machine-default*  qemu        2 days ago  Currently running  4           5.859GiB    100GiB

podman version 4.7.2

Steps to reproduce the issue

Create a podman machine and start it
let it running for a while
after a some hours, machine stop to answer

Describe the results you received

Connection refused or connection hanging

podman ps is blocking

podman machine ssh as well

Describe the results you expected

it should work

podman info output

macOS Sonoma

inspect of the machine:

podman machine inspect


[
     {
          "ConfigPath": {
               "Path": "/Users/benoitf/.config/containers/podman/machine/qemu/podman-machine-default.json"
          },
          "ConnectionInfo": {
               "PodmanSocket": {
                    "Path": "/Users/benoitf/.local/share/containers/podman/machine/qemu/podman.sock"
               },
               "PodmanPipe": null
          },
          "Created": "2023-11-06T18:24:20.266785+01:00",
          "Image": {
               "IgnitionFilePath": {
                    "Path": "/Users/benoitf/.config/containers/podman/machine/qemu/podman-machine-default.ign"
               },
               "ImageStream": "testing",
               "ImagePath": {
                    "Path": "/Users/benoitf/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-38.20231027.2.0-qemu.aarch64.qcow2"
               }
          },
          "LastUp": "2023-11-07T10:49:04.99063+01:00",
          "Name": "podman-machine-default",
          "Resources": {
               "CPUs": 4,
               "DiskSize": 100,
               "Memory": 6000
          },
          "SSHConfig": {
               "IdentityPath": "/Users/benoitf/.ssh/podman-machine-default",
               "Port": 55861,
               "RemoteUsername": "core"
          },
          "State": "running",
          "UserModeNetworking": true,
          "Rootful": false
     }
]

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional information

I started podman with DEBUG output so I have a qemu window

we can see virtio_net virtio0 enp0s1: TX timeout on queue: 0, sq: output.0, vq: 0x1, name: output.0 messages

I need to do

ifconfig enp0s1 down and then ifconfig enp0s1 up and then network is restored in the machine

podman info output when it's working back:

host:
  arch: arm64
  buildahVersion: 1.32.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc38.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 99.66
    systemPercent: 0.15
    userPercent: 0.18
  cpus: 4
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: coreos
    version: "38"
  eventLogger: journald
  freeLocks: 2038
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
    uidmap:
    - container_id: 0
      host_id: 501
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
  kernel: 6.5.8-200.fc38.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 2644602880
  memTotal: 6041264128
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.8.0-1.fc38.aarch64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.8.0
    package: netavark-1.8.0-2.fc38.aarch64
    path: /usr/libexec/podman/netavark
    version: netavark 1.8.0
  ociRuntime:
    name: crun
    package: crun-1.10-1.fc38.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.10
      commit: c053c83c57551bca13ead8600237341818975974
      rundir: /run/user/501/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20231004.gf851084-1.fc38.aarch64
    version: |
      pasta 0^20231004.gf851084-1.fc38.aarch64-pasta
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/501/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-1.fc38.aarch64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 24h 11m 57.00s (Approximately 1.00 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 7
    paused: 0
    running: 0
    stopped: 7
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 106769133568
  graphRootUsed: 7597252608
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 8
  runRoot: /run/user/501/containers
  transientStore: false
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.7.0
  Built: 1695839065
  BuiltTime: Wed Sep 27 20:24:25 2023
  GitCommit: ""
  GoVersion: go1.20.8
  Os: linux
  OsArch: linux/arm64
  Version: 4.7.0

The text was updated successfully, but these errors were encountered:

baude · 2023-11-09T14:06:18Z

@benoitf thanks for the write up and the fact that you have a solution is a good thing. I doubt there is much podman can do about this except to use this an anchor issue. I am curious if you are able to observe this same behavior with vfkit directory or if you could try to reproduce outside of podman?

@gbraad @cfergeau has either of you observed this?

baude · 2023-11-09T14:08:07Z

ah! reading closer, it clearly says this is qemu ... so vfkit and friends are off the hook!

benoitf · 2023-11-09T14:10:38Z

I found this issue as well coreos/fedora-coreos-tracker#1463 but it should have been already solved :-/
and yes it's using qemu

cfergeau · 2023-11-09T14:14:14Z

@gbraad @cfergeau has either of you observed this?

There are known rare network connectivity issues observed with vfkit, hyperv, and this one. Hard to say if this is the same issue as it's not easily reproducible. The common component between all of these is gvisor-tap-vsock, which happens to be the component which would be reading the data transmitted by virtio-net (the logs complain about virtio_net TX timeout).
Hence I would put the blame on gvproxy, maybe somewhere in this code? https://github.com/containers/gvisor-tap-vsock/blob/main/pkg/tap/switch.go
Need to experiment on my machine to see what kind of debug is possible/not possible with gvproxy ran by podman, and work with Florent to extract more info when this happens.

baude · 2023-11-09T15:00:52Z

@cfergeau i would agree about the gvproxy as plausible place to start digging ... one thing i am having trouble reconciling though is why removing the mod and re-installing it would "fix" gvproxy?

@benoitf is it possible to say that the machine never hibernated before exhibiting this behavior ?

benoitf · 2023-11-09T15:03:07Z

@baude my computer is probably suspending/hibernating/resume/etc during this amount of time. I would not assume the machine was always on/no suspend/etc

cfergeau · 2023-11-09T15:37:38Z

one thing i am having trouble reconciling though is why removing the mod and re-installing it would "fix" gvproxy?

This is one of the open questions for which I need to look closer at gvproxy's code. virtio-net TX/RX queues are bound somehow to the unix socket RX/TX buffers on the host. Unloading/reloading virtio-net could reset enough state to get network traffic to flow again between the guest and the host (blind guess, I really need to look closer at all this code ^^ )

Or maybe this has nothing to do with gvisor-tap-vsock and it is a kernel bug similar to coreos/fedora-coreos-tracker#1463 (which Florent mentioned)

baude · 2023-11-09T15:43:38Z

@cfergeau appreciate your help here! tyvm.

azolotko · 2023-11-13T16:20:47Z

When running podman with --debug, I also noticed that the QEMU VM itself seems to be doing just fine. If I define an additional network interface via QEMU options, I can still reach the VM without any troubles. It's only the network interface served by gvproxy, i.e. -netdev socket,id=vlan,fd=3 -device virtio-net-pci,netdev=vlan, is dead.

For the record, I'm running macOS Sonoma 14.1.1 (23B81) @ Apple M1 Pro.

podman version 4.7.2

cfergeau · 2023-11-13T16:33:51Z

It's only the network interface served by gvproxy, i.e. -netdev socket,id=vlan,fd=3 -device virtio-net-pci,netdev=vlan, is dead.

This is consistent with what Florent pointed out in the issue description, ifdown/ifup on the interface served by gvproxy fixes networking. Reloading the virtio-net module has the same effect.

benoitf · 2023-11-21T13:36:32Z

closing as I'm not reproducing it with latest FCOS version/latest gvproxy version

CA-Demetriade · 2023-11-21T18:34:53Z

closing as I'm not reproducing it with latest FCOS version/latest gvproxy version

I'm testing FCOS stable latest with my team!

Also, I would like to understand what new change fixes this issue. I'm looking at the 39.20231101.3.0's release notes

Edit:
We got the unresponsive issue with fedora-coreos-39.20231101.3.0-qemu.aarch64.qcow2... @benoitf which latest version of FCOS are you referencing? I see other latest versions under test and next tab including kernel and other package updates.

Developer 1:

Developer 2:

benoitf · 2023-11-21T20:05:08Z

hello @CA-Demetriade

I'm using Fedora CoreOS 39.20231119.2.0 but before I was using your version

I'm also using the latest version of gvproxy binary (depending on the installation method you pickup maybe it's an old version)
https://github.com/containers/gvisor-tap-vsock/releases

benoitf · 2023-11-21T20:05:49Z

for reference: https://fedoraproject.org/coreos/release-notes?arch=aarch64&stream=testing

CA-Demetriade · 2023-11-21T20:27:40Z

Thank you @benoitf for your answer!

We are using Podman 4.7.2 (downloaded from homebrew).
When I dig into this release in Github, I see that it's using gvproxy 5.0 instead of 0.7.1... But, when I check the brew formula, it installs gvproxy 0.7.1 (latest)

Concerning FCOS, I was using the latest version of stable instead of the test branch. I'll do other test with 39.20231119.2.0

CA-Demetriade · 2023-11-22T15:39:11Z

We got the same freezing issue with fedora-coreos-39.20231119.2.0-qemu.aarch64.qcow2...

cfergeau · 2023-11-22T15:46:36Z

This issue was a networking issue, causing for example podman machine ssh to hang.
After seeing your screenshot, I'm not sure how it relates to this issue.

slemeur · 2023-11-22T17:29:25Z

@baude : Does this remind you another issue: #20639 (comment) ?

benoitf · 2023-11-22T17:46:02Z

@CA-Demetriade i would suggest to run podman machine --log-level=DEBUG (so you have a QEMU prompt)

connect with podman machine ssh change the password and then login in the QEMU console

if it freezes you could do some inspection from the QEMU terminal (if networking is not working)

cfergeau · 2023-11-23T16:01:29Z

To check if the issue you are seeing is similar to this one, once you have a qemu console and the issue occurs, you can rmmod virtio_net; modprobe virtio_net, or try the ifup/ifdown commands described at the beginning of the issue:

ifconfig enp0s1 down and then ifconfig enp0s1 up and then network is restored in the machine

CA-Demetriade · 2023-11-23T18:29:13Z

@cfergeau I confirm that rmmod virtio_net; modprobe virtio_net fixed the issue. Podman is now responding... until another freeze I guess.

benoitf · 2023-11-24T09:52:57Z

reopening as I'm hitting the issue again with everything being up-to-date

CA-Demetriade · 2023-11-24T13:32:28Z

I'm using Symantec Endpoint Protection on my Mac, so maybe it's related to this issue on the RedHat customer portal
https://access.redhat.com/solutions/4293681

I don't have a RedHat subscriber account, so I can't read about the issue.

fabricepipart1a · 2023-12-19T08:56:55Z

Should you undocument brew in this page?
https://podman-desktop.io/docs/installation/macos-install

gbraad · 2023-12-19T09:07:27Z

@fabricepipart1a Let me know the result after this. Got conflicting remarks; some say it worked, while others say it didn't

fabricepipart1a · 2023-12-19T09:17:55Z

Surely I will report if problem is gone. But be aware that podman and podman desktop were also upgraded in the process

fabricepipart1a · 2023-12-20T08:54:45Z

I uninstalled everything from brew (podman-desktop and podman-cli). I reinstalled 1.6.3 from official installer.
And this morning:

$ podman ps
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman socket: failed to connect: ssh: handshake failed: read tcp 127.0.0.1:54816->127.0.0.1:51142: read: connection reset by peer

Would you like me to collect any evidence before I stop and start my VM?

jeffmaury · 2023-12-20T09:17:23Z

Can you try to identify the path of the qemu process that is running ?

fabricepipart1a · 2023-12-20T09:32:13Z

Seems OK to me:

 ╰─ ps -efl | grep qemu
  502 73344     1   0  6:11PM ttys007    0:09.90 /opt/podman/qemu     4006  31  0 409286688  28720 -      S                   0
  502 73345     1   0  6:11PM ttys007   14:35.54 /opt/podman/qemu     4006  31  0 422540560 820704 -      R                   0

gbraad · 2023-12-20T11:14:40Z

If you want to try if the new vfkit driver works, you can try to start Podman Machine as follows:

$ export CONTAINERS_MACHINE_PROVIDER=applehv
$ podman machine init
Downloading VM image: fedora-coreos-39.20231204.2.1-applehv.aarch64.raw.gz: done
Extracting compressed file: podman-machine-default_fedora-coreos-39.20231204.2.1-applehv.aarch64.raw: done
Machine init complete

Note: someone on my team has been able to repro the issue even with the qemu binary we specifically made; it was hard to get it doing this, but seems it is a Qemu+kernel related issue. If you can test with the vfkit/applehv setup, that would be much appreciated. for CRC we haven't seen issues for over a year with that virtualization stack.

Note 2: since it is still an early release, it seems the vfkit driver is not installed automagically. See: #21064 so an additional download step is needed, https://github.com/crc-org/vfkit/releases

fabricepipart1a · 2023-12-20T13:09:28Z

Let's go !

╰─ export CONTAINERS_MACHINE_PROVIDER=applehv

╰─ brew tap cfergeau/crc && brew install vfkit
...
🍺  /opt/homebrew/Cellar/vfkit/0.5.0: 5 files, 15.7MB, built in 1 minute 14 seconds
...


╰─ podman machine init --cpus 8 --memory 12000 --rootful --user-mode-networking --now
Downloading VM image: fedora-coreos-39.20231204.2.1-applehv.aarch64.raw.gz: done
Extracting compressed file: podman-machine-default_fedora-coreos-39.20231204.2.1-applehv.aarch64.raw: done
Machine init complete
Starting machine "podman-machine-default"
...

Machine "podman-machine-default" started successfully

fabricepipart1a · 2023-12-21T09:17:49Z

Results this morning are promising! VM is perfectly fine and operational.
Are there any expected differences between vfkit and qemu?

Like disk or network performance?

gbraad · 2023-12-21T09:19:28Z

The disk performance might be slightly improved, as is virtio shares. network should be similar.

I have seen a report that sharing home failed with permission denied, though think this came from SELinux instead.

rhatdan · 2023-12-21T15:00:51Z

Yes there is an issue with relabeling read/only files from the MAC, but everything else works.

fabricepipart1a · 2023-12-22T07:48:44Z

Feedback of the day regarding the usage of vfkit

First, I have an issue. Podman desktop UI does not see my VM at all. I am unsure it did see it yesterday. But this morning, Podamn Desktop app acts like if I had never created any podman-machine.
Even if:

╰─ podman machine list
NAME                    VM TYPE     CREATED        LAST UP            CPUS        MEMORY      DISK SIZE
podman-machine-default  applehv     3 minutes ago  Currently running  8           11.72GiB    100GiB

Second, I just realized that UserModeNetworking is reported as false by podman machine inspect

╰─ podman machine inspect
[
     {
          "ConfigPath": {
               "Path": ...containers/podman/machine/applehv/podman-machine-default.json"
          },
          "ConnectionInfo": {
               "PodmanSocket": {
                    "Path": ".../podman/machine/applehv/podman.sock"
               },
               "PodmanPipe": null
          },
          "Created": "2023-12-22T08:41:46.345445+01:00",
          "Image": {
               "IgnitionFilePath": {
                    "Path": ".../containers/podman/machine/applehv/podman-machine-default.ign"
               },
               "ImageStream": "testing",
               "ImagePath": {
                    "Path": ".../containers/podman/machine/applehv/podman-machine-default_fedora-coreos-39.20231204.2.1-applehv.aarch64.raw"
               }
          },
          "LastUp": "0001-01-01T00:00:00Z",
          "Name": "podman-machine-default",
          "Resources": {
               "CPUs": 8,
               "DiskSize": 100,
               "Memory": 12000,
               "USBs": null
          },
          "SSHConfig": {
               "IdentityPath": ".../.ssh/podman-machine-default",
               "Port": ...,
               "RemoteUsername": "core"
          },
          "State": "running",
          "UserModeNetworking": false,
          "Rootful": true
     }
]

And then finally, I don't seem able to throw ssh commands:

╰─ podman machine ssh date
Error: read /Users/fpipart/.config/containers/podman/machine/applehv: is a directory

jeffmaury · 2023-12-22T09:35:50Z

Feedback of the day regarding the usage of vfkit

First, I have an issue. Podman desktop UI does not see my VM at all. I am unsure it did see it yesterday. But this morning, Podamn Desktop app acts like if I had never created any podman-machine. Even if:

╰─ podman machine list
NAME                    VM TYPE     CREATED        LAST UP            CPUS        MEMORY      DISK SIZE
podman-machine-default  applehv     3 minutes ago  Currently running  8           11.72GiB    100GiB

Second, I just realized that UserModeNetworking is reported as false by podman machine inspect

╰─ podman machine inspect
[
     {
          "ConfigPath": {
               "Path": ...containers/podman/machine/applehv/podman-machine-default.json"
          },
          "ConnectionInfo": {
               "PodmanSocket": {
                    "Path": ".../podman/machine/applehv/podman.sock"
               },
               "PodmanPipe": null
          },
          "Created": "2023-12-22T08:41:46.345445+01:00",
          "Image": {
               "IgnitionFilePath": {
                    "Path": ".../containers/podman/machine/applehv/podman-machine-default.ign"
               },
               "ImageStream": "testing",
               "ImagePath": {
                    "Path": ".../containers/podman/machine/applehv/podman-machine-default_fedora-coreos-39.20231204.2.1-applehv.aarch64.raw"
               }
          },
          "LastUp": "0001-01-01T00:00:00Z",
          "Name": "podman-machine-default",
          "Resources": {
               "CPUs": 8,
               "DiskSize": 100,
               "Memory": 12000,
               "USBs": null
          },
          "SSHConfig": {
               "IdentityPath": ".../.ssh/podman-machine-default",
               "Port": ...,
               "RemoteUsername": "core"
          },
          "State": "running",
          "UserModeNetworking": false,
          "Rootful": true
     }
]

And then finally, I don't seem able to throw ssh commands:

╰─ podman machine ssh date
Error: read /Users/fpipart/.config/containers/podman/machine/applehv: is a directory

Podman Desktop does not see your machine because it relies on CONTAINERS_MACHINE_PROVIDER to be set so if you want Podman Desktop to have it, you should set it in your login shell, don't know exactly how to do on MacOS.

benoitf · 2023-12-22T09:47:15Z

machine provider should be set in containers.conf file to be seen globally and not having to export env variable before running each podman command

https://github.com/containers/common/blob/main/docs/containers.conf.5.md

line provider=

fabricepipart1a · 2023-12-22T10:42:27Z

OK let's go
code /Users/<user>/.config/containers/containers.conf

...
[machine]
provider="applehv"
...

Indeed convenient not to have to set the env var.
If you doubted, podman machine ssh date still does not work (while podman machine ssh does work).
Also podman machine inspectstill reports that user mode networking is not activated (I did not clarify yet if I had proper connectivity though).

benoitf · 2023-12-22T11:46:09Z

podman machine ssh <command> failing looks like a bug (in fact even podman machine ssh podman-machine-default is not working while should work)

report may not be accurate (for user network mode)

rhatdan · 2023-12-22T12:36:37Z

Please open separate issues for what you have found. We need to get to the point where we can make applehv the default.

fabricepipart1a · 2023-12-26T12:58:26Z

I opened #21090 and #21091

benoitf · 2023-12-26T13:12:42Z

thanks @fabricepipart1a

fabricepipart1a · 2023-12-26T17:45:50Z

I opened #21092 to cover the main issue I have with applehv.

gbraad · 2024-01-11T20:29:22Z

We have been in touch with some people, like Sergio Lopez, to discuss if this was related to the virtualization stack and how networking is set up, besides the use of our gvproxy/user-mode networking. It has been confirmed that this is the case, while we have a few patches to mitigate this for Qemu, this has to be resolved for qemu+virtio. We will be doing this outside of the scope of this issue.

Instead, we have a few PRs lined up that modify the transmission buffer, and 'bounces' the network.

gbraad · 2024-01-17T09:50:23Z

Awaiting feedback from @benoitf on #21262 if this can be called 'resolved'. This is a temporary solution, called "health recovery service" to restart the network, for only Qemu on macOS... until this is resolved by the virtualization stack qemu+virtio.

gbraad · 2024-01-17T14:07:08Z

FYI: cherrypicked for 4.9

benoitf · 2024-01-17T15:01:38Z

I confirm that the patch is allowing to workaround the issue 👍

cfergeau · 2024-02-07T08:58:59Z

I guess this can be closed now?

benoitf · 2024-02-07T09:08:36Z

closing as with the workaround/bouncing of the interface it's staying alive now

thanks to all the people involved

benoitf added the kind/bug Categorizes issue or PR as related to a bug. label Nov 9, 2023

github-actions bot added the remote Problem is in podman-remote label Nov 9, 2023

benoitf added the podman-desktop label Nov 9, 2023

benoitf mentioned this issue Nov 9, 2023

Connection to /events drops sometimes podman-desktop/podman-desktop#4712

Closed

cfergeau mentioned this issue Nov 13, 2023

Networking issues containers/gvisor-tap-vsock#296

Open

benoitf closed this as completed Nov 21, 2023

benoitf reopened this Nov 24, 2023

n1hility mentioned this issue Jan 16, 2024

Add a net health recovery service to qemu machines #21262

Merged

benoitf closed this as completed Feb 7, 2024

stale-locking-app bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label May 8, 2024

stale-locking-app bot locked as resolved and limited conversation to collaborators May 8, 2024

podman machine on macOS becomes unresponsive after some time #20639

podman machine on macOS becomes unresponsive after some time #20639

Comments

benoitf commented Nov 9, 2023 • edited Loading

Issue Description

Steps to reproduce the issue

Describe the results you received

Describe the results you expected

podman info output

Podman in a container

Privileged Or Rootless

Upstream Latest Release

Additional environment details

Additional information

baude commented Nov 9, 2023

baude commented Nov 9, 2023

benoitf commented Nov 9, 2023

cfergeau commented Nov 9, 2023

baude commented Nov 9, 2023

benoitf commented Nov 9, 2023

cfergeau commented Nov 9, 2023 • edited Loading

baude commented Nov 9, 2023

azolotko commented Nov 13, 2023 • edited Loading

cfergeau commented Nov 13, 2023

benoitf commented Nov 21, 2023

CA-Demetriade commented Nov 21, 2023 • edited Loading

benoitf commented Nov 21, 2023

benoitf commented Nov 21, 2023

CA-Demetriade commented Nov 21, 2023

CA-Demetriade commented Nov 22, 2023

cfergeau commented Nov 22, 2023

slemeur commented Nov 22, 2023

benoitf commented Nov 22, 2023

cfergeau commented Nov 23, 2023

CA-Demetriade commented Nov 23, 2023

benoitf commented Nov 24, 2023

CA-Demetriade commented Nov 24, 2023

fabricepipart1a commented Dec 19, 2023

gbraad commented Dec 19, 2023

fabricepipart1a commented Dec 19, 2023

fabricepipart1a commented Dec 20, 2023

jeffmaury commented Dec 20, 2023

fabricepipart1a commented Dec 20, 2023 • edited Loading

gbraad commented Dec 20, 2023 • edited Loading

fabricepipart1a commented Dec 20, 2023

fabricepipart1a commented Dec 21, 2023

gbraad commented Dec 21, 2023

rhatdan commented Dec 21, 2023

fabricepipart1a commented Dec 22, 2023

jeffmaury commented Dec 22, 2023

benoitf commented Dec 22, 2023

fabricepipart1a commented Dec 22, 2023 • edited Loading

benoitf commented Dec 22, 2023

rhatdan commented Dec 22, 2023

fabricepipart1a commented Dec 26, 2023 • edited Loading

benoitf commented Dec 26, 2023

fabricepipart1a commented Dec 26, 2023

gbraad commented Jan 11, 2024

gbraad commented Jan 17, 2024

gbraad commented Jan 17, 2024

benoitf commented Jan 17, 2024

cfergeau commented Feb 7, 2024

benoitf commented Feb 7, 2024

benoitf commented Nov 9, 2023 •

edited

Loading

cfergeau commented Nov 9, 2023 •

edited

Loading

azolotko commented Nov 13, 2023 •

edited

Loading

CA-Demetriade commented Nov 21, 2023 •

edited

Loading

fabricepipart1a commented Dec 20, 2023 •

edited

Loading

gbraad commented Dec 20, 2023 •

edited

Loading

fabricepipart1a commented Dec 22, 2023 •

edited

Loading

fabricepipart1a commented Dec 26, 2023 •

edited

Loading