podman: podman pod ps aborts with Error: container [...] not found in DB: no such container
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
❯ podman pod ps
Error: container 85ea779d81e95632061[...] not found in DB: no such container
Steps to reproduce the issue:
- Create a pod and interrupt the process in the wrong moment?
Describe the results you received:
❯ podman pod ps
Error: container 85ea779d81e95632061[...] not found in DB: no such container
Describe the results you expected:
No error message. Empty list or a list containing POD_ID **broken** or similar would be have acceptable. Possibly with instructions on how to recover.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
❯ podman version
Version: 3.4.0
API Version: 3.4.0
Go Version: go1.15.15
Built: Mon Oct 4 19:52:18 2021
OS/Arch: linux/amd64
Output of podman info --debug:
❯ podman info --debug
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers: []
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.30-2.fc33.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.30, commit: '
cpus: 12
distribution:
distribution: fedora
version: "33"
eventLogger: journald
hostname: [...]
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 5.14.11-100.fc33.x86_64
linkmode: dynamic
logDriver: k8s-file
memFree: 43901960192
memTotal: 67135229952
ociRuntime:
name: crun
package: crun-1.0-1.fc33.x86_64
path: /usr/bin/crun
version: |-
crun version 1.0
commit: 139dc6971e2f1d931af520188763e984d6cdfbf8
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
exists: true
path: /run/user/1000/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: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.12-2.fc33.x86_64
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.3.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.0
swapFree: 4294963200
swapTotal: 4294963200
uptime: 5h 39m 18.66s (Approximately 0.21 days)
plugins:
log:
- k8s-file
- none
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
store:
configFile: /home/dschridde/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.7.1-2.fc33.x86_64
Version: |-
fusermount3 version: 3.9.3
fuse-overlayfs: version 1.7.1
FUSE library version 3.9.3
using FUSE kernel interface version 7.31
graphRoot: /home/dschridde/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 192
runRoot: /run/user/1000/containers
volumePath: /home/dschridde/.local/share/containers/storage/volumes
version:
APIVersion: 3.4.0
Built: 1633369938
BuiltTime: Mon Oct 4 19:52:18 2021
GitCommit: ""
GoVersion: go1.15.15
OsArch: linux/amd64
Version: 3.4.0
Package info (e.g. output of rpm -q podman or apt list podman):
❯ rpm -q podman
podman-3.4.0-1.fc33.x86_64
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora 33 on a regular workstation.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (19 by maintainers)
Commits related to this issue
- Remove infra ID from DB before removing containers If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operations would ... — committed to mheon/libpod by mheon 3 years ago
- Remove infra ID from DB before removing containers 65;6203;1c If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operati... — committed to mheon/libpod by mheon 3 years ago
- Remove infra ID from DB before removing containers If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operations would ... — committed to mheon/libpod by mheon 3 years ago
- Remove infra ID from DB before removing containers If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operations would ... — committed to mheon/libpod by mheon 3 years ago
- Remove infra ID from DB before removing containers If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operations would ... — committed to mheon/libpod by mheon 3 years ago
- Remove infra ID from DB before removing containers If we interrupt pod removal between removing containers and removing the whole pod, the infra ID was still in the DB, and most pod operations would ... — committed to mheon/libpod by mheon 3 years ago
Fix should be in #12047