Bugzilla – Bug 1141726
When wicked is enabled NetworkManager does not update resolv.conf
Last modified: 2021-08-11 16:27:26 UTC
It is possible to install and start both wicked and NetworkManager. Since wicked is the default this is the case in most situations when you install NM. When you don't disable the wicked service before starting NetworkManager it starts and connects to networks but does not update resolv.conf This is probably related to only one of the daemons owning the network service. However, if NM wants to not run when wicked is enabled it should not run at all. If it runs it should provide all services, including updating resolv.conf
Just stop wicked if you want to use NetworkManager instead. By the way, you can/should switch between between NetworkManager and wicked in the network settings in yast.
I can stop it, sure. The problem is it is not enforced that wicked is stopped before starting NM, and for whatever reason NM is not fully working when not stopped/disabled.
@Jonathan: can we add some crafted conflicts to either wicked or network manager service files?
(In reply to Dominique Leuenberger from comment #3) > @Jonathan: can we add some crafted conflicts to either wicked or network > manager service files? Just tested this solution(added Conflicts in NetworkManager.service file) and it doesn't quite work. Starting wicked while NetworkManager is running works well. But starting NM while wicked is running causes the whole computer to be offline. Looking into the journal, this seems to be caused by wicked not finishing quitting even when NM is up running. When wicked finally quits, the internet connection is down as well.
It does (and can not) work at all with NetworkManager enabled: https://bugzilla.opensuse.org/show_bug.cgi?id=1180234
How is this supposed to work? I suppose systemd sends some signal to the service when you want to stop it but how does it determine that it has stopped? It should track the service processes, and only claim it stopped once they all exit. Or does wicked do something to escape this process tracking by systemd?