systemd: reduce systemd-networkd-wait-online timeout to 10s

[miaoqing-quic]

Most contemporary Linux systems typically use either systemd-networkd or NetworkManager. Having both enabled can lead to timeouts, as both NetworkManager-wait-online.service and systemd-networkd-wait-online.service wait for the network to be up.

This configuration often results in long boot delays when one service blocks waiting for an interface that the other is managing.

To mitigate this, add a drop-in configuration file (override-timeout.conf) that reduces the systemd-networkd-wait-online timeout to 10 seconds.

CRs-Fixed: 4426645

[koenkooi]

Do we actually have a requirement for a system to be online? If not, we can disable the wait completely.

[miaoqing-quic]

systemd-networkd was previously disabled on QLI 1.0, but that caused other network regressions, so we chose to set the timeout to 10 instead.

Reference:
https://www.baeldung.com/linux/systemd-networkd-wait-online-service-timeout-solution

[lumag]

Which one do we use inside qcom-distro? systemd-networkd or NM? The other one should be disabled.

systemd-networkd was previously disabled on QLI 1.0, but that caused other network regressions

Pointer?

[miaoqing-quic]

Both systemd-networkd and NetworkManager are in use. Please refer to CR4062530 for details.

[lumag]

Both systemd-networkd and NetworkManager are in use. Please refer to CR4062530 for details.

This is a public discussion.

[miaoqing-quic]

I didn’t quite understand your point. Previous discussions on this issue were all shared via internal links.

[lumag]

I didn’t quite understand your point. Previous discussions on this issue were all shared via internal links.

Is your link related to the previous breakage or to the using of both daemons? In the latter case, please provide at least a summary, why do we need both.

[miaoqing-quic]

CR4062530 is related to using both daemons. When systemd-networkd was disabled and only NetworkManager was enabled, WLAN was found not to work on the first boot on QCM6490.LE.1.0.
Therefore, this CR reverted the changes that disabled systemd-networkd.

[koenkooi]

systemd-networkd was previously disabled on QLI 1.0, but that caused other network regressions, so we chose to set the timeout to 10 instead.

Reference: https://www.baeldung.com/linux/systemd-networkd-wait-online-service-timeout-solution

I'll ask again: Do we actually have a requirement for a system to be online? If not, we can disable the wait completely.

That's option 8 in the link you posted.

[lumag]

WLAN was found not to work on the first boot

Why?

[ricardosalveti]

Most contemporary Linux systems typically use either systemd-networkd or NetworkManager. Having both enabled can lead to timeouts, as both NetworkManager-wait-online.service and systemd-networkd-wait-online.service wait for the network to be up.

This configuration often results in long boot delays when one service blocks waiting for an interface that the other is managing.

You have a few options here:

• Disable networkd in systemd, and rely only on NetworkManager (which we use in order to facilitate the wifi usage)
• Change to only wait on any interface (https://www.baeldung.com/linux/systemd-networkd-wait-online-service-timeout-solution#1-wait-for-any-interface). This will unblock as soon there is at least on network interface configured, which is the option we use in the foundries lmp distro.

[ricardosalveti]

Reducing the timeout value is wrong as it will give the impression to the system that network is actually online, which is not true necessarily.

[ricardosalveti]

I'll ask again: Do we actually have a requirement for a system to be online? If not, we can disable the wait completely.

It delays network-online.target, which can be used by services depending on a valid network setup. I don't think we should disable this.

[koenkooi]

I'll ask again: Do we actually have a requirement for a system to be online? If not, we can disable the wait completely.

It delays network-online.target, which can be used by services depending on a valid network setup. I don't think we should disable this.

That sounds like we need to fix it at a different level:

1. Adjust our configs to make networkd+networkmanager coexist better, for example using netplan as backend for both.
2. Adjust targets that don't absolutely need network to stop depending on network-online.target.

[ricardosalveti]

2. Adjust targets that don't absolutely need network to stop depending on network-online.target.

That helps, but I believe the current issue is that systemd-networkd-wait-online is waiting for all the interfaces to be up, not only one, and that is why adding --any should probably be enough.