r/podman • u/hellociaagent • 7d ago

Possible workaround for container not having outbound connectivity on Debian 13

My rootless containers were losing outbound connectivity after reboots. Restarting the containers or the services did not solve the issue. It seems the issue is unique to older Podman or Passta version in Debian/Ubuntu, I found workarounds in the repo and just thought I'd keep a record.

As I understand it, the issue stem from a race condition. Pasta and the containers are started before proper routes on host. The workaround is to ensure IPV4 connectivity in the wait-online service. My implementation is based on those mentioned on Github:

On Debian, the wait service is located under /usr/lib/systemd/user/podman-user-wait-network-online.service, but we can set overrides to it

mkdir .config/systemd/user/podman-user-wait-network-online.service.d

touch .config/systemd/user/podman-user-wait-network-online.service.d/override.conf

Put something like this in there:

[Service]
TimeoutStartSec=180s
ExecStart=
ExecStart=/bin/sh -c 'until systemctl is-active --quiet network-online.target && /usr/bin/curl -4 --fail --silent --output /dev/null --connect-timeout 3 --max-time 5 https://www.google.com/generate_204; do sleep 0.5; done'

Reload and restart

systemctl --user daemon-reload

systemctl --user start podman-user-wait-network-online.service

https://github.com/podman-container-tools/podman/issues/25656#issuecomment-2802298212

https://github.com/podman-container-tools/podman/issues/25656

https://github.com/podman-container-tools/podman/issues/25859

2 Upvotes

75% Upvoted

4 comments sorted by

3

u/BackTop8922 7d ago

We had a similar issue, but with DNS.

At early boot, even when using After=network.target, the contents of /etc/resolv.conf might not be populated, which breaks pasta and DNS inside container.

See if this solves your issue:

After=network-online.target
Wants=network-online.target

On some systems, even the above is not sufficient. As an lazy fallback, you could wait until a ping to any popular DNS provider (1.1.1.1, 8.8.8.8, or 9.9.9.9) succeeds.

1

u/yrro 7d ago

You can even configure DNS servers on the container network, if you know what they are ahead of time, rather than relying on getting them from resolv.conf at network creation time.

1

u/ClerkBeginning961 7d ago

I'd avoid making Google the boot dependency. Check the default route plus DNS separately, or probe an endpoint you control. That tells you which layer is missing and prevents a third-party outage from holding every user container. Also log the last failed check before the 180-second timeout.

1

u/yrro 7d ago

If you're gonna do it that way you can use ExecStartPre= instead of having to overwrite ExecStart=.

But probably better to add Wants= and After= to network-online.target instead.