https://bugzilla.suse.com/show_bug.cgi?id=1212627 https://bugzilla.suse.com/show_bug.cgi?id=1212627#c8 --- Comment #8 from Adam Majer <amajer@suse.com> --- (In reply to Jonathan Kang from comment #7)

(In reply to Adam Majer from comment #6)

...

Created attachment 867859 [details] fails after NetworkManager

With additional changes,

# /etc/systemd/system/sshd.service.d/01-after-network.conf [Unit] After=NetworkManager-wait-online.service

[Service] Restart=always RestartSec=5s RestartPreventExitStatus=

SSHD comes up *most of the time* while still failing sometimes. That is, Network Maanger signals via NetworkManager-wait-online.service that it is complete, but the IP address is still not available for bind by SSHD. I've attached a log that shows exactly this.

...

sshd[1225]: error: Bind to port 22 on 2a01:4f8:c012:9cdf:0:aead:1:aead failed: Cannot assign requested address

sshd waits for an ipv6 address, is this intentional? In this logs you provided, when sshd starts, there is already an ipv4 address available. But there is no ipv6 address assigned yet.

The IPv4 address is non-routable and configured via DHCP, and the only public address available is the IPv6. It's configured manually, so it's not like there is a long wait for RA or something, ipv6.method: manual ipv6.dns: 2a01:4ff:ff00::add:1,2a01:4ff:ff00::add:2 ipv6.dns-search: -- ipv6.dns-options: -- ipv6.dns-priority: 0 ipv6.addresses: 2a01:4f8:c012:9cdf::1/64, 2a01:4f8:c012:9cdf:0:aead:1:aead/64 ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: -- ipv4.dns-priority: 0 ipv4.addresses: -- In the "old days", all network interfaces should be configured as much as possible before the rest of the system is signaled that network is ready. So, passive configuration via RA for IPv6 would be out-of-scope for this wait but everything else should be blocking. Static IP assignments should definitely be all assigned prior to signaling network setup is successful. Basically, I would expect all configured network interfaces to be up and configured completely before proceeding. It's not OR condition here but AND. Optionally things could proceed after some timeout, like 2 or 3 minutes, if we are waiting for external resources that may be failing (eg. DHCP) Finally, an answer here that "it would work if you just listen on wildcard address" is not really a good answer here. -- You are receiving this mail because: You are on the CC list for the bug.