[Bug 895447] yast2 lan leaves part of NetworkManager running
![](https://seccdn.libravatar.org/avatar/3035b38ff33cf86f480bb169b8500b80.jpg?s=120&d=mm&r=g)
http://bugzilla.suse.com/show_bug.cgi?id=895447
--- Comment #9 from Dominique Leuenberger
(In reply to Dominique Leuenberger from comment #7)
(In reply to Marius Tomaschewski from comment #6)
(In reply to Dominique Leuenberger from comment #4)
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/data/ NetworkManager.service.in?id=1d89bc0004ec27fbc0c89f17861118c78d7eeab5 and the referenced bug (https://bugzilla.redhat.com/show_bug.cgi?id=876218#c49) have a very nice story why NM is not tearing down the network on 'systemctl stop NetworkManager'
=> on a shutdown, if you have a NFS mounted root, the root 'disappears' on you and the shutdown hangs...
Ah... yes. Then I'd say: kill -9 dhclient in this case would do the right thing (same as sysconfig were doing before ;-)
done by what? if we don't want it and do not care for remote FS root, then we can disable this and simply kill the network on the go;
By NM when there is a remote FS.
if NM were to do that: then the shutdown issue as described in the referenced git commit will be happening: once the network is down, you don't have access to those remote FS anymore (and if this is the wish, then we simply patch out the KillMode=Process away)
Question would be: what is more common: - User switching NM off completely to switch to wicked (if done through Yast, yast should be able to take care of terminating dhclient as well) if done by means of services, well, the user better know what he does :)
Skilled user -- perhaps: when he notices this left over. Otherwise there is dhclient running and breaking the currently used network service.
The not skilled user would switch using Yast... which should have the knowledge of what to do to properly switch... switching is certainly not the daily task...
of
updating NetworkManager package and triggering a restart (on Factory this happens often... )
=> I'm in favor of keeping NM the way it is; and for the case of a user switching between NM and wicked, have yast to the right things (which would mean for this bug: 'wontfix'...it actually does not describe an explicit issue after all
It is IMO definitely not a WONTFIX as it breaks networking. The new service isn't able to work properly when the old leaves running dhcp clients.
switching is not a daily task and should get it's sep handling in the switching code... there I don't object it terminating more tasks.. on a simple restart of the NM service, it just sounds wrong. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com