Pasta can't bind ports on boot

[cj-wong]

Hello,

I have not been able to figure out how to get pasta to bind ports of containers on boot. Because I can just restart the container a short time later and it works, I assume pasta is not ready to bind ports when it does.

My setup:

• amd64 computer
• Debian 13, podman version 5.4.2
• containers run in quadlets
• pasta networking

Relevant error messages:

Failed to bind port <redacted> (Cannot assign requested address) for option '-t <redacted>'
Error: pasta failed with exit code 1:
Failed to bind port <redacted> (Cannot assign requested address) for option '-t <redacted>'
<redacted>.service: Main process exited, code=exited, status=126/n/a

What can I do to address this? Should I be adding a wait period before starting? I did not have this issue when I was on Debian 12, podman version 4.3.1 (when the default network was slirp4netns), but I understand that it's because slirp4netns is slower than pasta, to the point that it can bind ports "on time", so to speak.

[Luap99]

yes you need to wait until your interface that you link to bindto becomes online.

It is a quite common issues that the user session starts before the network is ready. If you use quadlet there should already be a dependency on podman-user-wait-network-online.service which polls the systems network-online.target for readiness. But that also is problemeatic when the system unit is never activated, i.e. #24796

[cj-wong]

It seems for my system that the workaround in there doesn't work. network-online.target also appears to be active when I check. I suppose I would have to just add a dummy service, which my containers would then depend on, that waits before exiting.

[chennin]

Problem

suggested solution below under TLDR

Hi! Same problem, same distro, same version. Pasta is only listening on [::] on boot and connections to ipv4 fail with Connection refused whereas ipv6 do something!

$ ss -ntlp
State           Recv-Q          Send-Q                                 Local Address:Port                    Peer Address:Port         Process
LISTEN          0               128                                             [::]:9100                            [::]:*             users:(("pasta.avx2",pid=1526,fd=8))
$ nc -v 127.0.0.1 9100
nc: connect to 127.0.0.1 port 9100 (tcp) failed: Connection refused
$ nc -v ::1 9100
Connection to ::1 9100 port [tcp/*] succeeded!
PING
HTTP/1.1 400 Bad Request

Restarting the (user rootless Quadlet) container after boot makes it work

$ systemctl --user restart nginx.service
$ ss -ntlp
State           Recv-Q          Send-Q                                 Local Address:Port                    Peer Address:Port         Process
LISTEN          0               128                                                *:9100                               *:*             users:(("pasta.avx2",pid=3872,fd=8))
$  nc -v 127.0.0.1 9100
Connection to 127.0.0.1 9100 port [tcp/*] succeeded!
GET / HTTP/1.0

HTTP/1.1 400 Bad Request

This is a Quadlet that IS waiting on podman-user-wait-network-online.service, but I suspect that the root cause is that Debian 13 by default does not use systemd for networking, and so systemd-networkd-wait-online.service doesn't even wait? Check out those timestamps below, the "network is online" seconds before either address is even on the interface.

I tried making it wait for ipv4 and 6 addresses to appear (IPv6: SLAAC, IPv4: DHCP, slow) and that didn't work.

# journalctl -b0 | grep -E "adding address|leased|Network is"
Dec 29 17:20:35 jade systemd[1]: Reached target network-online.target - Network is Online.
Dec 29 17:20:38 jade ifup[786]: eth0: adding address 2001:0DB8::1/64
Dec 29 17:20:42 jade ifup[786]: eth0: leased 192.0.2.2 for 1800 seconds
# networkctl list
systemd-networkd is not running, output might be incomplete.
IDX LINK       TYPE     OPERATIONAL SETUP
  1 lo         loopback -           unmanaged
  2 eth0       ether    -           unmanaged

By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to be online.

TLDR

Anyway try swapping to systemd-networkd. Worked for me after one single reboot 🤞

You may also want to make network-online wait for ipv4 and 6 to appear, if like my VPS your DHCPv4 is seconds slower. I didn't try without it, I'm done rebooting to test this for now.

# systemctl edit systemd-networkd-wait-online.service

[Service]
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -4 -6 -i eth0

Aftermath

/usr/lib/systemd/systemd-networkd-wait-online (this is manually running it, not the service) doesn't time out anymore

# networkctl list
IDX LINK       TYPE     OPERATIONAL SETUP
  1 lo         loopback carrier     unmanaged
  2 eth0       ether    routable    configured
#  journalctl -b0 | grep -E "DHCPv4 address|Network is"
Dec 29 18:04:27 jade systemd-networkd[751]: eth0: DHCPv4 address 192.0.2.2/24, gateway 192.0.2.1 acquired from 10.0.0.1
Dec 29 18:04:29 jade systemd[1]: Reached target network-online.target - Network is Online.

(I don't see when systemd logs my IPv6 SLAAC address, but it also existed before 18:04:30)