GNOME Bugzilla – Bug 779920
[RFE] adding support to check for a specific interface with nm-online
Last modified: 2020-11-12 14:26:14 UTC
Created attachment 347726 [details] [review] nm-online.c patch Hello, i hope you will find this patch usefull and will integrate it into nm-online. As i'm new in doing things in C, please give me some advise to improve this patch. Motivation: I have a small server box with multiple interfaces and some services on it. One of the services bind to a specific IP. If the specific interface IP is not up at system startup, then the service startup will fail. So i told systemd to wait starting the service until NetworkManager-wait-online is finished. But it did not work, as it seems that nm-online reports a success, when any of the connections are up. So i added some code to nm-online to check for a specific interface is up. See patch attached and give me some feedback. regards Kai
Hi Kai, NetworkManager-wait-online calls `nm-online --wait-for-startup`... that is, it waits until NetworkManager declares "startup complete" (grep for that in the logfile). > But it did not work, as it seems that nm-online reports a success, when any of > the connections are up. this certainly sounds like a bug, startup complete should not be reached before all interfaces reach a state where no further actions are expected. The patch waits until the device reaches state ACTIVATED. If you have both IPv4 and IPv6 addressing, the device may be already in state activated, when only one of the address family completes. So, it's not clear that the patch does what you want... Maybe we should expose the device property "NM_DEVICE_HAS_PENDING_ACTION" on D-Bus, and nm-online could wait until the device has no pending actions (in addition to reaching the ACTIVATED state). Beniamino, what do you think?
Hi Kai, as Thomas said, --wait-for-startup should already ensure that NM activates all devices for which there is a connection profile having autoconnect=yes, before returning. If this doesn't happen, maybe we should fix this instead of adding a new option. Can you please share NM logs of boot at TRACE level (set 'level=TRACE' in the [logging] section of /etc/NetworkManager/NetworkManager.conf and reboot the system). You can find NM logs in the journal ('journalctl -u NetworkManager -b') or probably somewhere in /var/log, depending on your distro. Thanks!
Created attachment 347856 [details] NM trace log
Hello guys, thanks for your explanations. I understood your objections. The log of NM trace is attached above. I booted the system with vanilla NM, so nm-online is not patched in any way. I have still two services (nmbd and smbd) not starting when the box is booting. The nmbd log says: "bind failed on port 137 socket_addr = 192.168.0.1." Both have "After=network-online.target" in the unit file. My configuration is: enp0s31f6 -> IPv4 (fixed address) enp2s0 & enp3s0 -> bond0 (Adaptive load balancing) bond0 -> IPv4 (fixed address) Thank you very much! regards Kai
how about https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/startup-complete-race-bgo779920 ?
(In reply to Thomas Haller from comment #5) > how about > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/startup- > complete-race-bgo779920 ? It's not clear to me how much this would be an improvement, because (if I understand correctly), the patch only moves check_if_startup_complete() to an idle source, which will run an unknown amount of time later, possibly very short. I think we should make this more deterministic and if there are uninitialized links, wait for at most N seconds before declaring startup complete. BTW, the fact that links can be initialized after NM has started has also a bad impact on the new ordering of interfaces by name at boot [1], but it seems not feasible to completely block activations while there are uninitialized links. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1420708
(In reply to Beniamino Galvani from comment #6) > (In reply to Thomas Haller from comment #5) > > how about > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/startup- > > complete-race-bgo779920 ? how about now? Also reworded commit messages, which should answer your remark.
(In reply to Thomas Haller from comment #7) > (In reply to Beniamino Galvani from comment #6) > > (In reply to Thomas Haller from comment #5) > > > how about > > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/startup- > > > complete-race-bgo779920 ? > > how about now? > > Also reworded commit messages, which should answer your remark. Yes, it does. LGTM now.
thanks. Branch merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=7cb3928c499c0a5a7d70a03c93256540dea47321 I think this should delay startup-complete sufficiently in case of comment 3. Kai, would be great if you could test this. As to whether add support for a --iface argument of nm-online. In order to do that, I think the property "NM_DEVICE_HAS_PENDING_ACTIONS" should be exposed on D-Bus (possibly with a better name). And nm-online would have to wait until the device is in state ACTIVATED *and* has no pending actions. I think that might make sense, but the priority of this feature that doesn't seem high to me. I leave the bug open for that.
Hi Thomas, not working for me, so i investigated further. I found that the service files of nmbd and smbd has not "Wants=network-online.target" declared. I added this and now it's working (also with installed version 1.6.2). Anyway, i will test your patch again in a clean virtual machine over the weekend. thank you & regards Kai
Hi, tested cases: NM 1.6.2 w/o "Wants=network-online.target" => nmbd/smbd start fail NM 1.6.2 with "Wants=network-online.target" => nmbd/smbd start ok NM inkl. your patch w/o "Wants=network-online.target" => nmbd/smbd start fail NM inkl. your patch with "Wants=network-online.target" => nmbd/smbd sart ok Not using "Wants=network-online.target" is bad in any case. Using this, fixed it for me. Improved the NM code also, isn't bad anyway. :-) Having a --iface option or smth. like that in nm-online would be awesome also. Thanks and have a nice weekend. regards Kai
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).