I've switched from distro networking stack (wicked) to systemd-network;
generally, what a relief!
The distro (opensuse leap 15.1) has 'old' systemd -- v234
As packaged,
'systemd-network.service' has "Also=systemd-networkd-wait-online.service".
&
'systemd-networkd-wait-online.service' has "WantedBy=network-online.target"
A number of my services depend on 'network-online.target'.
All this^ is to say -- if 'network-online.target' is used,
'systemd-networkd-wait-online.service' gets launched.
My box ALSO has a bridge defined.
Which causes me to hit
"systemd-networkd-wait-online fails with bridged interfaces"
https://github.com/systemd/systemd/issues/2154
on boot,
[ 151.868637] systemd-networkd-wait-online[1394]: Event loop failed:
Connection timed out
[ 151.884034] systemd[1]: systemd-networkd-wait-online.service: Main
process exited, code=exited, status=1/FAILURE
[ 151.885593] systemd[1]: Failed to start Wait for Network to be
Configured.
[ 151.885714] systemd[1]: systemd-networkd-wait-online.service: Unit
entered failed state.
[ 151.885741] systemd[1]: systemd-networkd-wait-online.service: Failed
with result 'exit-code'.
which causes significant delay
systemd-analyze critical-chain
multi-user.target @2min 50.841s
└─...
└─network-online.target @2min 19.876s
└─network.target @19.712s
└─systemd-networkd.service @19.268s +409ms
└─network-pre.target @19.249s
└─...
The solution @bug is -- upgrade to systemd v242.
On this distro, upstream refuses to upgrade systemd; apparently for them its
'non trivial' and they can't be bothered. AND, they've a new 'stable' version
coming out AnyDayNow(tm), Leap 15.2, for which apparently systemd will REMAIN
at broken-like-this^^ v234.
So *my* solution has been to switch distros. NOT just for this^^ reason, but
it was the last straw ...
~ 600 machines have finished migrating to other distros with newer systemd
installs that avoid this problem.
BUT -- I'm left with a few boxes that I can't move for awhile.
So ...
IS there a backport of this^^ fix available for v234 that popped up in
the meantime?
If not, as is likely, is there a "safe" workaround for quieting the
fail, and rm'ing the associated boot delay? Is rm'ing either the "Also=" or
"WantedBy=" a reasonable band-aid?
Or, some other approach?
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
