podman ps: hangs #658

edsantiago · 2018-04-23T15:34:12Z

Every so often my system gets into a state where podman ps hangs. It's in such a state right now, and I was able to strace it. I think this is the relevant portion:

openat(AT_FDCWD, "/var/run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae", O_RDWR|O_CREAT, 0600) = 18
fcntl(18, F_SETFD, FD_CLOEXEC)          = 0
getrandom("\x32\xc9\x80\xa9\x0b\x3e\xda\x92\x7b\xbc\xea\x28\xbb\x69\x87\x01\xa9\x92\xc6\x22\x08\xc4\x03\xda\xd9\xbf\x77\x86\x6c\x23\xff\x04", 32, 0) = 32
munmap(0x7f4ec2fff000, 8388608)         = 0
flock(16, LOCK_UN)                      = 0
close(16)                               = 0
getpid()                                = 2017
fcntl(18, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

^^^ this is where it's hanging

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

edsantiago · 2018-04-23T15:34:28Z

Whoops: podman-0.4.4.1524346805-gitcf1d884.fc27.x86_64

mheon · 2018-04-23T15:40:15Z

Looks like it's hanging on the lock.
Any other processes going at the same time?

mheon · 2018-04-23T15:40:40Z

Podman processes, I mean

edsantiago · 2018-04-23T15:41:14Z

# lsof /var/run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                      
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME        
podman   2017 root   18u   REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                       
podman   3926 root   32u   REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                       
podman  10563 root   18uW  REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                       
podman  17179 root   32u   REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                       
podman  23415 root   32u   REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae                       
podman  29860 root   32u   REG   0,23        0 546679 /var/../run/libpod/lock/87e6d0d059aa31c85ad412680277a9e05badda21e3c96810070de1232a431eae

# ps auxww|grep podman                          
root      2015  0.0  0.0  12288  1756 pts/2    S+   15:32   0:00 strace podman ps
root      2017  0.0  0.5 592784 23320 pts/2    Sl+  15:32   0:00 podman ps
root      3926  0.0  0.5 592432 22648 pts/0    Sl+  15:34   0:00 /usr/bin/podman ps -a --no-trunc
root      5674  0.0  0.0  12936  1052 pts/3    S+   15:37   0:00 grep --color=auto podman
root     10563  0.0  0.5 520044 23156 pts/0    Tl+  14:54   0:00 /usr/bin/podman attach --sig-proxy=true attach_sigproxy_stress_ttyoff-test_0z9s
root     17179  0.0  0.5 592784 21860 pts/0    Sl+  15:04   0:00 /usr/bin/podman ps -a --no-trunc
root     23415  0.0  0.5 592432 21108 pts/0    Sl+  15:14   0:00 /usr/bin/podman ps -a --no-trunc
root     29860  0.0  0.5 592432 21192 pts/0    Sl+  15:24   0:00 /usr/bin/podman ps -a --no-trunc

mheon · 2018-04-23T15:42:29Z

They're all stuck on a specific container's lock. Alright. So we have a race with many ps running against each other.

mheon · 2018-04-23T15:45:28Z

10563 seems to have the lock. It looks like it's stuck in the critical section and not releasing the lock.
Can you kill 10563 and see if things start working again?

edsantiago · 2018-04-23T15:47:38Z

Yes, that got things unstuck.

mheon · 2018-04-23T15:48:01Z

OK. It's 10563 holding that lock. That's podman attach. So this seems to be a locking bug with attach.

mheon · 2018-04-23T16:36:38Z

I have a suspicion that it might be https://github.com/projectatomic/libpod/blob/master/libpod/container_api.go#L411-L416 in attach - that's one of our more unusual uses of locking. I can't see an obvious way in which that would fail, but there could be a timing condition of some sort that locks attach into that critical section.

It's one of only two places where attach grabs a lock on a container, the other being a call to container.Status(), which is about as foolproof of an API call as we have.

mheon · 2018-04-23T16:44:29Z

The obvious conclusion is that we're getting stuck somewhere on the boltdb lock, so we never hit the Unlock() in attach.go

mheon · 2018-04-23T16:51:59Z

That actually can't be true. If it was the case, ps would not even get this far - it would fail to even retrieve the container. The lock issue has to be the container lock itself.

mheon · 2018-04-23T16:54:23Z

We must be getting stuck in syncContainer(). This has three basic portions: update container from database, update container from runc, save container status back to database. Given what I said in the last comment, this can't be the DB lock, so I strongly suspect our reading status from runc is hanging somehow?

mheon · 2018-04-23T17:03:55Z

Wait, attach is showing as stopped in the ps output, and the test container says sig-proxy... @edsantiago Is there any chance you're sending a SIGSTOP to the attach process as part of that test? We can't forward SIGSTOP, it's uncatchable, but if we got one right as we were in a critical section we will never release locks.

edsantiago · 2018-04-23T17:24:02Z

This is strange. First: yes, the container was indeed stopped at the time of this situation; I had to kill -CONT it for my other kills to take effect.

But... this should not be part of the test. 19 is very definitely excluded from the signal list. The debug logs do not show any part of the tests sending that signal. I've tried to reproduce manually and can't figure out how the container ended up stopped. But yes, it looks like this is a smoking gun.

Continuing to look; will update if I find anything.

edsantiago · 2018-04-23T18:01:20Z

@mheon is there any possibility that podman attach is (occasionally, somehow) stopping the container? That would explain some spurious errors I see in this particular test.

mheon · 2018-04-23T18:34:02Z

@edsantiago I don't think it's podman - the only place we send signals should be podman kill and podman stop.

ipmb · 2018-04-27T02:59:15Z

I'm seeing the same thing, but it is hanging on a different lock.

# strace podman ps
...
stat("/var/lib/containers/storage/vfs", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/var/lib/containers/storage/storage.lock", O_RDWR|O_CREAT, 0600) = 5
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
getrandom("\xcb\x49\xe7\x22\xb0\x9f\xac\xe0\x82\xd4\x93\xa5\x02\x19\xee\x04\xab\xd1\xe2\x8e\xbf\x19\xbc\x2a\x02\x2e\xde\xf0\x2f\x39\x22\x1c", 32, 0) = 32
getpid()                                = 20095
fcntl(5, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

# lsof /var/lib/containers/storage/storage.lock
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
podman   9277 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock
podman   9449 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock
podman  19624 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock
podman  19679 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock
podman  23091 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock
podman  31179 root    3u   REG    8,1       64 537033 /var/lib/containers/storage/storage.lock

# ps auxww | grep podman
root      9277  0.0  1.1 893604 23396 ?        Ssl  Apr26   0:07 /usr/bin/podman run ...
root      9449  3.9  1.0 733120 22048 ?        Ssl  Apr26   8:22 /usr/bin/podman run ...
root     19624  0.0  0.9 584600 19884 ?        Ssl  02:44   0:00 /usr/bin/podman run ...
root     19679  0.0  0.9 510868 19576 ?        Ssl  02:44   0:00 /usr/bin/podman run ...
root     20236  0.0  0.0  11460  1020 pts/0    S+   02:56   0:00 grep --color=auto podman
root     23091  0.0  0.2 879528  5432 ?        Ssl  Apr26   0:00 /usr/bin/podman run ...
root     31179  0.0  1.0 815460 21640 ?        Ssl  Apr26   0:03 /usr/bin/podman run ...

mheon · 2018-04-27T03:10:32Z

That looks like a c/storage lock, so it should be a separate issue, but let's keep it here until we can get it localized. @ipmb Can you give the commands you're using to recreate this? podman ps at the same time as another command, lots of ps commands all at once...?

ipmb · 2018-04-27T03:36:34Z

I'm setting up the containers in systemd with a config mgmt system. The tasks shouldn't be happening in parallel, but in very rapid succession:

podman ps | grep {image}
podman pull {image} (if it doesn't exist)
podman rm {container}
podman run --name={container} ...
podman inspect {container}

This happens a handful of times as each container spins up. I've only seen it in testing on my mac which has a bunch of virtualization (hyperkit -> Docker -> podman on vfs), so lots of overhead. I've noticed I need to sleep for a few seconds to reliably inspect a container after the run command. On a "real" machine I can run them back-to-back with && and it always seems to work.

mheon · 2018-04-27T14:05:41Z

It seems we're blocking on c/storage's graphLock which is taken during major c/storage operations. I suspect we're seeing a race between inspect trying to grab the layer store to compute image size on disk, and some operation in podman run (on bare metal, run will probably complete before the next command begins, so no race). It can't be anything to do with image pull or container creation (the container won't be available for inspect, so you'll get a "No Such Container" error instead of a race). This means it's probably something to do with mounting the container.

rhatdan · 2018-06-04T20:59:17Z

I believe this is fixed now, please reopen if it still happens.

johanbrandhorst · 2019-09-20T21:05:28Z

I saw this today when automating something with the podman varlink API.

$ podman info
host:
  BuildahVersion: 1.10.1
  Conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.0, commit: e217fdff82e0b1a6184a28c43043a4065083407f'
  Distribution:
    distribution: manjaro
    version: unknown
  MemFree: 494456832
  MemTotal: 16569856000
  OCIRuntime:
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8
      commit: 425e105d5a03fabd737a126ad93d62a9eeede87f
      spec: 1.0.1-dev
  SwapFree: 17844539392
  SwapTotal: 18223570944
  arch: amd64
  cpus: 8
  eventlogger: file
  hostname: REDACTED
  kernel: 4.19.69-1-MANJARO
  os: linux
  rootless: true
  uptime: 149h 0m 53.01s (Approximately 6.21 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/REDACTED/.config/containers/storage.conf
  ContainerStore:
    number: 2
  GraphDriverName: vfs
  GraphOptions: null
  GraphRoot: /home/REDACTED/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 118
  RunRoot: /run/user/1000
  VolumePath: /home/REDACTED/.local/share/containers/storage/volumes

Again, killing one of the offending processes fixed the issue:

$ ps aux | grep podman
REDACTED     1135  4.1  0.4 1329772 66520 ?       Ssl  21:33   1:01 /usr/bin/podman varlink unix:/run/user/1000/podman/io.podman
REDACTED     1152  0.0  0.3 1182052 60296 ?       Ssl  21:33   0:00 /usr/bin/podman --root /home/REDACTED/.local/share/containers/storage --runroot /run/user/1000 --log-level error --cgroup-manager cgroupfs --tmpdir /run/user/1000/libpod/tmp --runtime runc --storage-driver vfs --events-backend file container cleanup 2a5ee875bae62eed4e3c7ac10c6868f1aba50e3629cb2a5319de3a09a402d3ee
REDACTED     3179  0.0  0.0   6272  2380 pts/3    S+   21:57   0:00 grep --colour=auto podman
REDACTED    12845  0.0  0.0 119636     0 ?        S    Sep16   0:00 /usr/bin/podman
$ kill 1135
$ ps aux | grep podman
REDACTED     3269  0.0  0.0   6272  2220 pts/3    S+   21:58   0:00 grep --colour=auto podman
REDACTED    12845  0.0  0.0 119636     0 ?        S    Sep16   0:00 /usr/bin/podman

The deadlock seemed to happen when I tried to call io.podman.GetContainer immediately after calling io.podman.StartContainer. The io.podman.GetContainer was stuck reading the response from the varlink API endpoint.

pgporada · 2019-12-14T07:00:38Z

I'm experiencing the podman ps hang when running a container with elevated privileges.

# podman version
Version:            1.7.0-dev
RemoteAPI Version:  1
Go Version:         go1.13.5
OS/Arch:            linux/amd64

strace podman ps

read(12, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 3536
read(12, "", 4096)                      = 0
close(12)                               = 0
munmap(0x7fbb4075c000, 131072)          = 0
flock(11, LOCK_UN)                      = 0
close(11)                               = 0
futex(0xc000060bc8, FUTEX_WAKE_PRIVATE, 1) = 1
openat(AT_FDCWD, "/var/lib/containers/storage/libpod/bolt_state.db", O_RDWR|O_CREAT|O_CLOEXEC, 0600) = 11
epoll_ctl(4, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1208089800, u64=140442343701704}}) = -1 EPERM (Operation not permitted)
epoll_ctl(4, EPOLL_CTL_DEL, 11, 0xc0001c8d9c) = -1 EPERM (Operation not permitted)
flock(11, LOCK_EX|LOCK_NB)              = 0
fstat(11, {st_mode=S_IFREG|0600, st_size=131072, ...}) = 0
pread64(11, "\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\355\332\f\355\2\0\0\0\0\20\0\0\0\0\0\0"..., 4096, 0) = 4096
fstat(11, {st_mode=S_IFREG|0600, st_size=131072, ...}) = 0
mmap(NULL, 131072, PROT_READ, MAP_SHARED, 11, 0) = 0x7fbb4075c000
madvise(0x7fbb4075c000, 131072, MADV_RANDOM) = 0
futex(0xc00008d2c8, FUTEX_WAKE_PRIVATE, 1) = 1
geteuid()                               = 0
munmap(0x7fbb4075c000, 131072)          = 0
flock(11, LOCK_UN)                      = 0
close(11)                               = 0
newfstatat(AT_FDCWD, "/var/run/libpod/exits/9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e", 0xc0004f61d8, 0) = -1 ENOENT (No such file or directory)
futex(0x560d3cd72408, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x560d3cd72408, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x560d3cd72408, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
...repeat futex ad ifinitum...

# ps aux | grep -E '(podman|conmon)' | grep -v grep
root       77082  0.0  0.0  77912  2104 ?        Ssl  01:42   0:00 /usr/bin/conmon --api-version 1 -s -c b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222 -u b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222 -r /usr/bin/crun -b /var/lib/containers/storage/overlay-containers/b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222/userdata -p /var/run/containers/storage/overlay-containers/b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222/userdata/pidfile -l k8s-file:/var/lib/containers/storage/overlay-containers/b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --log-level debug --syslog --conmon-pidfile /var/run/containers/storage/overlay-containers/b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /var/run/containers/storage --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /var/run/libpod --exit-command-arg --runtime --exit-command-arg crun --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mountopt=nodev,metacopy=on --exit-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222
root       78313  0.0  0.0  77912  2104 ?        Ssl  01:46   0:00 /usr/bin/conmon --api-version 1 -s -c 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e -u 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e -r /usr/bin/crun -b /var/lib/containers/storage/overlay-containers/9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e/userdata -p /var/run/containers/storage/overlay-containers/9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e/userdata/pidfile -l k8s-file:/var/lib/containers/storage/overlay-containers/9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --log-level debug --syslog --conmon-pidfile /var/run/containers/storage/overlay-containers/9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /var/run/containers/storage --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /var/run/libpod --exit-command-arg --runtime --exit-command-arg crun --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --storage-opt --exit-command-arg overlay.mountopt=nodev,metacopy=on --exit-command-arg --events-backend --exit-command-arg journald --exit-command-arg container --exit-command-arg cleanup --exit-command-arg 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e
root       77955  0.0  0.6 834632 53540 ?        Sl   01:44   0:00 /usr/bin/podman --root /var/lib/containers/storage --runroot /var/run/containers/storage --log-level debug --cgroup-manager systemd --tmpdir /var/run/libpod --runtime crun --storage-driver overlay --storage-opt overlay.mountopt=nodev,metacopy=on --events-backend journald container cleanup b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222

Issuing a kill -9 77955 against the b724da27eec1579deb0da6422983c2f54c6a3aeb25cbca356c2a3cb016b23222 container allows me to once again run podman ps.

Maybe this is unrelated, but when a container PID is killed on the host, podman is unable to remove it too.

$ sudo podman ps
CONTAINER ID  IMAGE                                COMMAND  CREATED             STATUS                 PORTS  NAMES
1b2e6aafb3b3  docker.io/plexinc/pms-docker:latest           About a minute ago  Up About a minute ago         strange_snyder
9d6c432b35e3  docker.io/plexinc/pms-docker:latest           22 minutes ago      Up 22 minutes ago             focused_benz

$ sudo podman stop 9d6
^C

$ sudo podman kill 9d6
2019-12-14T07:09:43.000357734Z: kill container: No such process
Error: error sending signal to container 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e: `/usr/bin/crun kill 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e 9` failed: exit status 1

baude · 2019-12-19T14:40:10Z

@pgporada have a reproducer we can try?

pgporada · 2019-12-19T15:22:00Z

Yes, start a container as follows

sudo podman run \
	--log-level debug \
	-d \
	-e PLEX_UID=1000 \
	-e PLEX_GID=1000 \
	-e TZ=America/New_York \
	--net=host \
	plexinc/pms-docker

Kill the PID of the container on the host via kill -9 ${PID} and then try to run podman ps and you'll see it hang indefinitely. Perhaps this is a different issue?

$ kill -9 ${PID}

$ podman ps
CONTAINER ID  IMAGE                                COMMAND  CREATED     STATUS         PORTS  NAMES
9d6c432b35e3  docker.io/plexinc/pms-docker:latest           5 days ago  Up 5 days ago         focused_benz

$ podman kill 9d6
2019-12-19T15:00:57.000058671Z: kill container: No such process
Error: error sending signal to container 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e: `/usr/bin/crun kill 9d6c432b35e3b7fffe53c682998fe4a487e8a986d51d56fe5bf6e5c00ee1961e 9` failed: exit status 1

$ podman ps
     <=== hanging indefinitely

baude · 2019-12-22T18:06:30Z

@pgporada when you say kill the pid of the container, what exactly are you killing?

@mheon dont we have issues when things get killed from underneath conmon?

mheon · 2019-12-22T21:29:52Z

It's conmon getting killed before the container, the container dying before conmon should be fine.

…

On Sun, Dec 22, 2019, 13:06 Brent Baude ***@***.***> wrote: @pgporada <https://github.com/pgporada> when you say kill the pid of the container, what exactly are you killing? @mheon <https://github.com/mheon> dont we have issues when things get killed from underneath conmon? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#658>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCFGDASDCEG7GT2U7OTQZ6UCPANCNFSM4E4AQJAQ> .

mheon · 2019-12-22T21:31:02Z

Conmon dying could hang us as we wait for the exit file, though.

…

On Sun, Dec 22, 2019, 16:29 Matthew Heon ***@***.***> wrote: It's conmon getting killed before the container, the container dying before conmon should be fine. On Sun, Dec 22, 2019, 13:06 Brent Baude ***@***.***> wrote: > @pgporada <https://github.com/pgporada> when you say kill the pid of the > container, what exactly are you killing? > > @mheon <https://github.com/mheon> dont we have issues when things get > killed from underneath conmon? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#658>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB3AOCFGDASDCEG7GT2U7OTQZ6UCPANCNFSM4E4AQJAQ> > . >

jwhonce added the bug label Apr 25, 2018

edsantiago mentioned this issue May 14, 2018

Running containers inside of a container environment (with docker-compose.yml) using podman? #746

Closed

rhatdan closed this as completed Jun 4, 2018

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

podman ps: hangs #658

podman ps: hangs #658

edsantiago commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

ipmb commented Apr 27, 2018

mheon commented Apr 27, 2018

ipmb commented Apr 27, 2018

mheon commented Apr 27, 2018

rhatdan commented Jun 4, 2018

johanbrandhorst commented Sep 20, 2019

pgporada commented Dec 14, 2019 •

edited

Loading

baude commented Dec 19, 2019

pgporada commented Dec 19, 2019 •

edited

Loading

baude commented Dec 22, 2019

mheon commented Dec 22, 2019 via email

mheon commented Dec 22, 2019 via email

podman ps: hangs #658

podman ps: hangs #658

Comments

edsantiago commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

mheon commented Apr 23, 2018

edsantiago commented Apr 23, 2018

edsantiago commented Apr 23, 2018

mheon commented Apr 23, 2018

ipmb commented Apr 27, 2018

mheon commented Apr 27, 2018

ipmb commented Apr 27, 2018

mheon commented Apr 27, 2018

rhatdan commented Jun 4, 2018

johanbrandhorst commented Sep 20, 2019

pgporada commented Dec 14, 2019 • edited Loading

baude commented Dec 19, 2019

pgporada commented Dec 19, 2019 • edited Loading

baude commented Dec 22, 2019

mheon commented Dec 22, 2019 via email

mheon commented Dec 22, 2019 via email

pgporada commented Dec 14, 2019 •

edited

Loading

pgporada commented Dec 19, 2019 •

edited

Loading