podman: Podman randomly stops forwarding traffic with pasta networking
Issue Description
When binding a port with
podman run -p 8080:8080 --network pasta $otherargs
at a random point in time after starting the container no more external traffic will be able to reach services bound inside the container. There are no log entries in journald, no network changes - and it happens completely at random, on multiple systems.
This works if its bound to a specific ip (127.0.0.1 for example) instead.
If i remember correctly this started happening around or shortly after the 4.5.0 release but still occurs after multiple passt and podman updates on Fedora since then.
Steps to reproduce the issue
Steps to reproduce the issue
- Start a podman container (rootless) with
--network pastaand a bound-p 8080:8080port - Access the working service (e.g. Mumble, gitea) and then wait (usually takes a day)
- Try to access the service again - Service now doesn’t respond
Describe the results you received
Nothing inside the container can respond to traffic anymore on external ips
Describe the results you expected
Services should still work
podman info output
arch: amd64
buildahVersion: 1.30.0
cgroupControllers:
- cpu
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.7-2.fc38.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.7, commit: '
cpuUtilization:
idlePercent: 99.2
systemPercent: 0.38
userPercent: 0.43
cpus: 8
databaseBackend: boltdb
distribution:
distribution: fedora
version: "38"
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: 6.4.4-200.fc38.x86_64
linkmode: dynamic
logDriver: journald
memFree: 238510080
memTotal: 8256086016
networkBackend: netavark
ociRuntime:
name: crun
package: crun-1.8.5-1.fc38.x86_64
path: /usr/bin/crun
version: |-
crun version 1.8.5
commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
rundir: /run/user/1000/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
remoteSocket:
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.2.0-12.fc38.x86_64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.3
swapFree: 7763914752
swapTotal: 8255434752
uptime: 309h 34m 23.00s (Approximately 12.88 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
- quay.io
store:
configFile: /home/tobias/.config/containers/storage.conf
containerStore:
number: 1
paused: 0
running: 1
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /home/tobias/.local/share/containers/storage
graphRootAllocated: 123086045184
graphRootUsed: 8763510784
graphStatus:
Backing Filesystem: btrfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 5
runRoot: /run/user/1000/containers
transientStore: false
volumePath: /home/tobias/.local/share/containers/storage/volumes
version:
APIVersion: 4.5.1
Built: 1685123928
BuiltTime: Fri May 26 19:58:48 2023
GitCommit: ""
GoVersion: go1.20.4
Os: linux
OsArch: linux/amd64
Version: 4.5.1
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
No response
Additional information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 26 (4 by maintainers)
Feel free to continue the discussion but be since the patch is applied (https://passt.top/passt/commit/?id=da0aeb9080c9d2e39b2ff600a9b2b03046ac219d), closing.
@waffshappen
I’ve made some changes that I think will fix the problem - essentially it just strips the lifetime information off the host address when copying it to the container. I have a branch here with the revised code. If you could try that out, that would be great.