Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On Sa, 11.07.20 22:54, PGNet Dev (pgnet@gmail.com) wrote: > cd /etc/systemd/network > grep Link -A1 * > 20-enp3s0.network:[Link] > 20-enp3s0.network-RequiredForOnline=no > -- > 20-enp5s0.network:[Link] > 20-enp5s0.network-RequiredForOnline=no Ah, eh. As it turns out we added that only in v242. See NEWS. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 7/11/20 11:05 PM, Paul Menzel wrote: > If systemd is still the same, your distribution upgrade wasn’t relevant to > the issue at hand, was it? no, I didn't state that it was. What's relevant is that I followed the suggested workaround made to me, and there was no observed effect. It was simply mentioned here on the off-chance that @ distro-upgrade some backport/patch/fix might have been implemented. Clearly it wasn't. > The upstream project only supports the latest two versions of systemd, which > currently are 244 and 245. Please report your issues to openSUSE. Lennart was kind enough to comment previously. I'm asking Lennart for additional comment on his recommendation ... made here, so asked here. > Please report your issues to openSUSE. as stated in my OP, it already has been. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
Dear PGNet, Am 12.07.20 um 07:54 schrieb PGNet Dev: On 6/16/20 1:35 AM, Lennart Poettering wrote: On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: 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? You could use RequiredForOnline= in the bridge's .network file to mark it as irrelevant for systemd-network-wait-online. On my current machine, just upgraded to new OS version (still same distro -- for the moment) I've, networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp3s0 ether no-carrier configuring 3 enp5s0 ether routableconfigured infc #3 is active; intfc #2 is unused I added to each cd /etc/systemd/network grep Link -A1 * 20-enp3s0.network:[Link] 20-enp3s0.network-RequiredForOnline=no -- 20-enp5s0.network:[Link] 20-enp5s0.network-RequiredForOnline=no and rebooted. still, there's a 2min delay on startup systemd-analyze blame | head 2min 284ms systemd-networkd-wait-online.service 5.803s dkms.service 5.409s rc-local.service 4.270s mariadb-custom.service 3.952s after-local.service 3.647s udisks2.service 2.985s rpcbind.service 2.936s mcelog.service 2.901s ca-certificates.service 2.878s smartd.service in dmesg, dmesg | grep wait-online -A1 -B1 [ 129.299191] systemd[1]: Started update geoipdb service. [ 130.961418] systemd-networkd-wait-online[1664]: Event loop failed: Connection timed out [ 130.971019] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [ 130.971276] systemd[1]: Failed to start Wait for Network to be Configured. [ 130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [ 130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. [ 130.974266] systemd[1]: Reached target Network is Online. other than the two interfaces I _do_ have -- and have set [Link] RequiredForOnline=no for, what's possibly _still_ causing this delay? this^ is, as before, with rpm -qa | grep ^systemd-2 systemd-234-lp152.30.1.x86_64 switching back to non-systemd-networkd network stack eliminates any such delay. not surprising, given the bug -- and certainly not ideal. If systemd is still the same, your distribution upgrade wasn’t relevant to the issue at hand, was it? The upstream project only supports the latest two versions of systemd, which currently are 244 and 245. Please report your issues to openSUSE. Kind regards, Paul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 6/16/20 1:35 AM, Lennart Poettering wrote: > On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: > >> 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? > > You could use RequiredForOnline= in the bridge's .network file to mark > it as irrelevant for systemd-network-wait-online. > > Lennart > > -- > Lennart Poettering, Berlin On my current machine, just upgraded to new OS version (still same distro -- for the moment) I've, networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp3s0 ether no-carrier configuring 3 enp5s0 ether routableconfigured infc #3 is active; intfc #2 is unused I added to each cd /etc/systemd/network grep Link -A1 * 20-enp3s0.network:[Link] 20-enp3s0.network-RequiredForOnline=no -- 20-enp5s0.network:[Link] 20-enp5s0.network-RequiredForOnline=no and rebooted. still, there's a 2min delay on startup systemd-analyze blame | head 2min 284ms systemd-networkd-wait-online.service 5.803s dkms.service 5.409s rc-local.service 4.270s mariadb-custom.service 3.952s after-local.service 3.647s udisks2.service 2.985s rpcbind.service 2.936s mcelog.service 2.901s ca-certificates.service 2.878s smartd.service in dmesg, dmesg | grep wait-online -A1 -B1 [ 129.299191] systemd[1]: Started update geoipdb service. [ 130.961418] systemd-networkd-wait-online[1664]: Event loop failed: Connection timed out [ 130.971019] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [ 130.971276] systemd[1]: Failed to start Wait for Network to be Configured. [ 130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [ 130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. [ 130.974266] systemd[1]: Reached target Network is Online. other than the two interfaces I _do_ have -- and have set [Link] RequiredForOnline=no for, what's possibly _still_ causing this delay? this^ is, as before, with rpm -qa | grep ^systemd-2 systemd-234-lp152.30.1.x86_64 switching back to non-systemd-networkd network stack eliminates any such delay. not surprising, given the bug -- and certainly not ideal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: > 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? You could use RequiredForOnline= in the bridge's .network file to mark it as irrelevant for systemd-network-wait-online. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
