Comment # 9 on bug 895447 from Dominique Leuenberger

(In reply to Marius Tomaschewski from comment #8)
> (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.