NetworkManager.service contains:

# NM doesn't want systemd to kill its children for it
KillMode=process

this obviously is the reason for dhclient to stick around... question would be why this was decided... will inquire about the full rationale.

This is quite important to not have multiple network services / dhcp clients
running at same time. They conflict with each other -- not other because they
try to configure the same interfaces but also: one client sends message, the
other gets the responses (e.g. ipv6 multicasts).

See also: https://bugzilla.suse.com/show_bug.cgi?id=893678#c17

(In reply to Dominique Leuenberger from comment #1)
> NetworkManager.service contains:
> 
> # NM doesn't want systemd to kill its children for it
> KillMode=process

Ah... thanks -- this explains a lot :-)

> this obviously is the reason for dhclient to stick around... question would
> be why this was decided... will inquire about the full rationale.

Thanks!

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...

I'd guess the reason for KillMode=process was the following:

On update, you want to restart NetworkManager, but not break the network
connectivity if possible [and thus probably the update].

A SIGTERM sent to dhclient would cause that it deconfigure the interface,
except it is stopped using "dhclient -x ifname" or kill -SIGKILL.

I'd say, we can reassign this bug to NetworkManager to handle the stop
and update cases properly.

(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 ;-)

(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;

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 :)

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

(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.
 
> 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.

> 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.

The problem is also: when you start dhclient again, the dhclient script
_may_ deconfigure the interface / address family it currently handles;
this depends on the script implementation of course.

(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.

The only possibility to workaround it in yast2-network I currently see,
would be to implement the "switch away from NM" like this -- and also
to document in the release notes (for users doing it manually):

  # bnc#895447: NetworkManager does not cleanup on stop
  # Ensure it is gone along with conflicting dhclients,
  # ... before we switch over to another network.service.
  systemctl --kill-who=all kill NetworkManager.service
  systemctl stop NetworkManager.service
  systemctl disable NetworkManager.service

Is this the way preferred by the NetworkManager?

(In reply to Marius Tomaschewski from comment #10)
> The only possibility to workaround it in yast2-network I currently see,
> would be to implement the "switch away from NM" like this -- and also
> to document in the release notes (for users doing it manually):
> 
>   # bnc#895447: NetworkManager does not cleanup on stop
>   # Ensure it is gone along with conflicting dhclients,
>   # ... before we switch over to another network.service.
>   systemctl --kill-who=all kill NetworkManager.service
>   systemctl stop NetworkManager.service
>   systemctl disable NetworkManager.service
> 
> Is this the way preferred by the NetworkManager?

Yes - the switching between Network services is a special thing and deserves special handling, without breaking more normal use cases.

*** Bug 893678 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (895447) was mentioned in
https://build.opensuse.org/request/show/281060 13.2 / sysconfig

openSUSE-RU-2015:0124-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 895447,900982,912891
CVE References: 
Sources used:
openSUSE 13.2 (src):    sysconfig-0.83.8-5.1

*** Bug 902771 has been marked as a duplicate of this bug. ***

SUSE-RU-2015:1163-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 895447,900982,909307,912891,930309
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12 (src):    sysconfig-0.83.8-7.1
SUSE Linux Enterprise Desktop 12 (src):    sysconfig-0.83.8-7.1

This bug may - or may not - have been fixed. I know that bug #893678 is fixed, an alleged duplicate of this one, but I can't say for sure whether this one is. My own opinion is that the two bugs were unrelated.

As part of these two bugs (bsc#1117636, bsc#1122194), we were testing if YaST or NM was leaving some process around (dhclient):


https://bugzilla.suse.com/show_bug.cgi?id=1117636
https://bugzilla.opensuse.org/show_bug.cgi?id=1122194

That seems to not be the case, and what was suggested at #10 was not needed at all.

So closing it as fixes for TW.

Fell free to reopen it if you found that there is anything still wrong which yast-network should do better.

Thnx!