Hi, I started digging into network.target/network-online.target dependencies and sshd is one of the rare services I have on all systems. While I provided some information in bug #1066615, I think this is a specific issue and may need more care and time to resolve. sshd.service now orders after network.target in hope it will start when network configuration is already finished. This more or less worked with the good old network.service. And according to a note in bug #1066615, an experiment suggest it works with static configuration. On the other hand, systemd documentation doesn't guarantee nor does NetworkManager. It is a potential race condition. Possibilities: 1) just remove After=network.service Default configuration will continue to work, configurations with specific listening IP address would require the administrator to manually configure e.g. solution #3. 2) just keep using After=network.service This differs from solution #1 in that it seems to work for static configurations. But as NetworkManager doesn't guarantee finishing static configurations before giving control back to systemd, this is a possible race condition. 3) use Wants=network-online.service After=network-online.service (Wants+After can be also done on both network.service and network-online.service for backwards compatibility) This is the correct way to wait for getting online according to systemd. With NetworkManager, this guarantees either connection to be successful, or a timeout (of 90 seconds, I think) to elapse. It unnecessarily delays the start of sshd as well as the overall boot time in case sshd doesn't need to listen on a specific IP. 4) use IP_FREEBIND and avoid network.service as well as network-online.service Server processes typically don't need to wait for network connectivity and since Linux 2.4 (according to ip(6)) it is easy to listen on IP addresses that are not yet configured. A patch for using IP_FREEBIND would IMO be a valuable addition even if it had to be carried for long time. On the other hand, if upstream is willing to accept linux conditional code, even better. It's pretty clear that #4 is my favorite solution and it doesn't seem to have any drawbacks except that it's a code modification ;).
It would be nice to have this figured out for the F21 release.
Adding IP_FREEBIND to portable OpenSSH looks like a fix which would be acceptable by upstream. Other than that, sshd isn't the only affected service, and it's not really a generic solution to expect server code to use Linux-specific code to run on Fedora. I think what's required is changing services which depend on interfaces being up to depend on network-online.target instead of network.target. Corinna
I wonder whether enabling IP_FREEBIND for all sockets (e.g. by modifying the kernel and setting something in /etc/sysctl.conf) would have any bad side effects.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still present in F31.
*** Bug 1352214 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
*** This bug has been marked as a duplicate of bug 1936538 ***