Package: openssh-server
Version: 1:8.4p1-5
Severity: important
openssh-server can fail to start if the user defines a specific interface.
the workaround meanwhile is to add "network-online.target" to the
systemd unit.
The issue noticeably occurs when the user decides to use
"systemd-networkd" for the configuration rather than
/etc/network/interfaces.
A bugreport was initially provided to systemd explaining the problem in
greater detail, however a lead maintainer replied that the bug is to be
forwarded to the server package in question.
-- a copy of this original bugreport to systemd/systemd-networkd is
here for further referencing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510
A server should not fail to "start" just because it is using a specific
interface.
I attempted to provide the suggestion for systemd/systemd-networkd
maintainers to give a policy of having "network-online.target" for
server programs but I was told that the issue is the specific
server-package in question. (only two server packages that I use often
have this problem, openssh-server and apache2)
journalctl -xe -u [package] -- shows nothing revealing than ".. failed
to bind to address x.x.x.x". "networkctl" -- all shows green
highlighting --- the .network definitions are all correct.
the problem seems to me the systemd policy of having
network-online.target as a practice for server unit files is not
enforced enough..
though the traditional ifup-networking scripts doesn't have this issue
afaict.
.. it happens more often when the user opts not to be using the default
networking.service and instead go with the newer systemd-networkd method
for bringing up interfaces during the bootup.
the user here is not at fault, and should be allowed to set specific
interfaces for the apache2 and ssh service.
(fwiw, -- prior setting up the workaround, both ssh and apache2 servers
will both exhibit the same binding-interface error, as shown in
journalctl.
However when starting these services manually: such as,
systemctl start apache2.service, and
systemctl start ssh.service
there is no problem at all starting these up
The interfaces are set at the system-level. There is no
dbus-triggered/Desktop-login interface settings.
The problem is systemd++network-online.target not set in the unit files.
Systemd and Server package maintainers should enforce a better policy so
that simple changes do not affect the ability to start the service.
)
(this bugreport is getting cc'd to the apache2 package -- as the problem
also exists with that package)
thanks