When starting a rootful container attached to a bridge, it can take up to (roughly) 30 seconds before the container is able to accept incoming traffic #29423
Unanswered
yorickpeterse
asked this question in
Q&A
Replies: 3 comments 2 replies
|
Forgot to add: the linked Reddit thread mentions using a Pod as a potential workaround. I experimented with this but it made no difference in my case. |
0 replies
|
when the network takes a while to accept connections, does podman hang for that time or return right away? is anything spiking in cpu usage ? anything in dmesg or the journal? |
2 replies
|
To get this info I restarted the service I've been using to test this ("shost" in the logs), then collected the necessary info.
journalctl outputHere the following line is from when the program inside the container is up and running: And this line is from the first time it's able to accept work (in this case HTTP requests): Here we can see there's a delay of roughly 13 seconds. And this is the dmesg output when this happens: dmesg outputWhen this happens, both |
|
To add an extra data point: I did some testing with firewalld enabling logging for everything, to see if it was perhaps the firewall blocking packets for some reason. Unfortunately, this doesn't reveal any new insight as no rejected/dropped packets are logged when testing the container, meaning this is unlikely to be a firewall issue. |
|
For those coming here facing the same issue, I ended up using the following quadlet to work around this: The trick here is the userns line which maps "root" in the container to a user on the host, combined with the |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I have a container defined like so:
This container is located in
/etc/containers/systemd/ssh-container.containerand runs as a rootful container.The associated network is defined as follows:
This is the output of
podman network inspectfor the network in question:[ { "name": "systemd-bridge", "id": "8b75bcba28bc8bbc86c799289d8db48e137eca216f4b0c5c18d8888f6eb0c781", "driver": "bridge", "network_interface": "br0", "created": "2026-08-07T13:30:32.44123257Z", "subnets": [ { "subnet": "10.10.0.0/16", "gateway": "10.10.0.1" }, { "subnet": "fd9d:b34d:66b6:ff2d::/64", "gateway": "fd9d:b34d:66b6:ff2d::1" } ], "ipv6_enabled": true, "internal": false, "dns_enabled": true, "network_dns_servers": [ "127.0.0.53" ], "ipam_options": { "driver": "host-local" }, "containers": { "1c44750741174f1a9947d52adb3881c1375c6adae07d402b00fe0a3bbe866460": { "name": "shost", "interfaces": { "eth0": { "subnets": [ { "ipnet": "10.10.0.2/16", "gateway": "10.10.0.1" }, { "ipnet": "fd9d:b34d:66b6:ff2d::2/64", "gateway": "fd9d:b34d:66b6:ff2d::1" } ], "mac_address": "6a:f3:c6:cc:52:3f" } } }, "b7facc0cb9f3fecd4c0f4faf714887501b5e2ff67f4d6feb3cdc82ad96a4e450": { "name": "ssh-container", "interfaces": { "eth0": { "subnets": [ { "ipnet": "10.10.0.4/16", "gateway": "10.10.0.1" }, { "ipnet": "fd9d:b34d:66b6:ff2d::4/64", "gateway": "fd9d:b34d:66b6:ff2d::1" } ], "mac_address": "0a:84:1a:b6:f3:b5" } } } } } ]The problem I am experiencing is similar to what is described in this Reddit post: when a container is started or restarted, sometimes it's able to immediately accept new network connections while in other instances it can take up to around 30 seconds. In all cases the program itself is indeed listening and ready to go, but for some reason the traffic isn't reaching the container.
Pinging the local container (using the IP
10.10.0.4in this case) produces a similar result: sometimes it works right away, other times it takes time before the container starts to respond. The issue goes away entirely when the container runs usingNetwork=host(provided you also remove theUserNSsetting).I have a second host running a different set of containers but largely uses the same underlying OS setup, and this host doesn't experience these issues. The only noteworthy difference I can think of is how the firewall is managed: on the host where all is well, I publish ports using
PublishPortwhere necessary.Both systems run Fedora Server 44 using bootc. Both use systemd-networkd instead of NetworkManager, though the problem occurs with both and so this shouldn't be relevant.
On the host where I'm having these issues, I instead manage the port forwarding manually using firewalld, combined with the
StrictForwardPorts=yessetting. This is necessary because I have a bunch of rules to block certain IPs from accessing my containers, and when ports are published usingPublishPortthose rules are bypassed. As an example, mypublic.xmlzone file looks like this:Here the rules towards the bottom handle the port forwarding for the container mentioned above.
I've spent a fair bit of time trying to figure out what is going on. Unfortunately, the behavior is not consistent and I'm not able to find anything interesting in the logs. For example, the veth devices reach their online/listening states almost instantly based on the log timings. STP is also disabled for the bridge. I've also not been able to find any details online (short of the linked Reddit post) about what might be causing this problem.
Has anybody experienced similar issues or have any idea on what might be causing this? Or is this perhaps a bug in Podman?
All reactions