This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 815243 - Even though NetworkManager was manually stopped, it gets restarted automatically via D-Bus
Even though NetworkManager was manually stopped, it gets restarted automatica...
Status: CLOSED DUPLICATE of bug 1039023
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
18
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
RejectedBlocker
: Reopened
: 801370 896639 (view as bug list)
Depends On:
Blocks: 909134
  Show dependency treegraph
 
Reported: 2012-04-23 04:00 EDT by Lubos Kocman
Modified: 2013-12-06 07:23 EST (History)
31 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 909134 (view as bug list)
Environment:
Last Closed: 2013-08-26 18:09:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
journal-log.txt (16.37 KB, text/plain)
2012-11-28 08:38 EST, Marko Myllynen
no flags Details

  None (edit)
Description Lubos Kocman 2012-04-23 04:00:36 EDT
Description of problem:

I'm using bridged networking created by scripts in sysconfig/network-scripts

for some reason gnome-shell restarts time by time and it breaks my connectivity

Version-Release number of selected component (if applicable):

gnome-shell-3.4.0-1.fc17.x86_64
NetworkManager-0.9.4.0-1.git20120328.fc17.x86_64


How reproducible:


Steps to Reproduce:
1. log into gnome-shell
2. systemctl stop NetworkManager.service
3. alt+f
4. type "r" as a command
5. see that NetworkManager + nm-applet is up&running
  
Actual results:

broken connectivity => systemctl stop NetworkManager.service && ifdown virbr0 && ifup virbr0


Expected results:

THIS SHOULD NOT HAPPEN

Additional info:
!!!! for some reason I'm getting gnome-shellrestarted periodically every few minutes with NetworkManager stopped.
Comment 1 Dan Williams 2012-04-23 12:47:12 EDT
NM shouldn't be autostarted by systemd; we have some stuff in place (namely /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service ) to ensure that doesn't happen.  To test this, if you're willing, if you stop NM manually with systemctl, then in a terminal (or VT) type "nmcli nm" what happens?  Is NM running after that command?  If so, it's a systemd bug, or the mechanism which we use to prevent NM autostarting is no longer correct.
Comment 2 Dan Winship 2012-04-23 13:17:48 EDT
Apr 23 13:04:57 laptop dbus[850]: [system] Activating via systemd: service name='org.freedesktop.NetworkManager' unit='dbus-org.freedesktop.NetworkManager.service'

It looks like dbus-daemon got changed to prefer SystemdService to Exec, and so now it will start NetworkManager on demand. (The "demand" here comes from trying to register ShellNetworkAgent with the AgentManager.)
Comment 3 Tim Flink 2012-04-26 15:17:51 EDT
If I'm understanding correctly, gnome-shell users who are using NM wouldn't hit this and it wouldn't affect the Desktop livecds. Would this cause problems for the other live spins?

Since this could be fixed with an update and doesn't seem to hit any F17 release criteria, I'm -1 blocker.

Unless one of the supported spins is adversely affected by this, I'm also -1 NTH.
Comment 4 Dan Winship 2012-04-26 15:49:07 EDT
(In reply to comment #3)
> If I'm understanding correctly, gnome-shell users who are using NM wouldn't hit
> this

Yeah. The bug is basically "NM always gets started if you're running gnome-shell". It has no effect if NM was already running.

> and it wouldn't affect the Desktop livecds. Would this cause problems for
> the other live spins

I don't know if it affects the fallback nm-applet, or KDE, etc. But anyway, it could only be a problem for spins that disabled NM by default *AND* also included some nm-applet-type program in their default desktop. Seems unlikely.
Comment 5 Adam Williamson 2012-05-03 14:02:58 EDT
Discussed at 2012-05-03 blocker review meeting. No criterion is cited and we cannot think of one this bug breaks. It doesn't affect any default configuration of F17 as even minimal installs now use NM. It can be fixed with an update. In view of all of the above, it is rejected as a blocker.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Dan Winship 2012-07-23 14:55:58 EDT
not enough info in this bug to determine why gnome-shell was crashing, and whatever it was was probably fixed anyway. Moving to NetworkManager for the "NM getting started even though it's disabled" thing.
Comment 7 Jirka Klimes 2012-07-24 09:52:46 EDT
(In reply to comment #2)
> Apr 23 13:04:57 laptop dbus[850]: [system] Activating via systemd: service
> name='org.freedesktop.NetworkManager'
> unit='dbus-org.freedesktop.NetworkManager.service'
> 
D-Bus configuration file
/usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service
contains:
Exec=/bin/false
SystemdService=dbus-org.freedesktop.NetworkManager.service

so that D-Bus knows that it should not auto-activate NM, but rather pass the request to systemd (via dbus-org.freedesktop.NetworkManager.service service alias):
signal sender=org.freedesktop.DBus -> dest=org.freedesktop.systemd1 serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.systemd1.Activator; member=ActivationRequest
   string "dbus-org.freedesktop.NetworkManager.service"

systemd knowns the alias through
Alias=dbus-org.freedesktop.NetworkManager.service
configured in /lib/systemd/system/NetworkManager.service
So, it tries to start NM via dbus-org.freedesktop.NetworkManager.service and it succeeds because there is link
/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service -> /lib/systemd/system/NetworkManager.services

(
systemctl enable NetworkManager.service
creates two links:
/etc/systemd/system/multi-user.target.wants/NetworkManager.service -> /lib/systemd/system/NetworkManager.service
and
/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service -> /lib/systemd/system/NetworkManager.services
)

I thought that the alias can be disabled/enabled through:
# systemctl disable dbus-org.freedesktop.NetworkManager.service
but it returns "Failed to issue method call: No such file or directory".

http://fedoraproject.org/wiki/Packaging:Systemd#DBus_activation actually suggest that it should work, however mschmidt told me that enable/disable works only for primary services, not aliases. That's why the alias link has to be removed manually, if NetworkManager.service shall be enabled and D-Bus activation disabled.

Anyway it would be a nice feature if 
systemctl enable dbus-org.freedesktop.NetworkManager.service and
systemctl disable dbus-org.freedesktop.NetworkManager.service
work and admins (users) could easily switch D-Bus activation on/off.
Comment 8 Dan Williams 2012-07-24 11:57:09 EDT
systemd does not have a way to keep services that are manually stopped from restarting.  Your two options are 'disable' and 'mask', where disable makes the service a manually-started one, including at boot time.  mask disables the service completely and it can no longer even be started manually.

So no, there's no equivalent to 'service NetworkManager stop' where the service will never be restarted again, since with systemd, stopping a service makes no guarantees about the future, it only stops the current instance.

So if you'd like to argue these points with systemd developers, feel free; but the bug is a change in behavior (for better or worse) between sysvinit service handling and systemd service handling.
Comment 9 Michal Schmidt 2012-07-24 12:16:34 EDT
As I said to Jirka on IRC, administrators are free to maintain the symlinks under /etc/systemd manually, they do not have to rely solely on systemctl enable/disable. So you can do:

rm /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service
systemctl daemon-reload

... to disable the DBus activation of NM.

I know about contrary opinions about the manual hadnling of the symlinks, and I disagree with them.

(In reply to comment #8)
> the bug is a change in behavior (for better or worse) between sysvinit
> service handling and systemd service handling.

I'm not sure I follow.
Before systemd took over the responsibility of starting services from dbus, there was no way to disable the activation of selected services, was there? With systemd you have the power to do that.
Comment 10 Bill Nottingham 2012-07-24 12:47:54 EDT
I believe it's a change in behavior in that NM wasn't bus activated before systemd, but I may be misremembering.
Comment 11 Pavel Šimerda (pavlix) 2012-07-24 15:10:32 EDT
There is no reason for NetworkManager to be bus activated.
Comment 12 udo 2012-07-25 10:01:28 EDT
Amen. NM needs to do what it is told to do. NM need not to decide for itself, should not duplicate udev functionality, etc.
NM needs a thorough redesign before being thrown at us ever again.

So what is the thing thet will stop the logging?
Comment 13 Michal Schmidt 2012-07-25 12:40:14 EDT
(In reply to comment #11)
> There is no reason for NetworkManager to be bus activated.

If there's no reason, why was DBus activation added to NM? Why does NM ship a DBus service activation file (/usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service)?

Hm, perhaps the reason was to allow DBus clients that want to talk with NM to start in parallel with it? In this case supporting the DBus activation could serve as an implicit ordering guarantee.
Comment 14 udo 2012-07-25 13:02:04 EDT
Perhaps this mechanism is too simple as it excludes the local factor of the admin/abuser/user.
For certain reasons certain (near)dependencies might be unavailable (disabled) or not even present at all.

FWIW: NM cannot cope with iPAQ's that do ether networking over USB with an ever changing mac address. The basic network scripts work 100% though.
That is one reason to disable NM as it has no added value; it can't even provide a `network is active and OK` icon this way as it destroys existing connections.
Then we decide to remove it. We notice dependency-hell.
Nothing is provided in those areas.
We cannot get 100% rid of NM.

We like to update the system ourselves so we do not need PackageKit.
Ever looked at PK? Ever tried to disable it? Remove it? We notice dependency-hell.
Nothing is provided in those areas.

And this is only a start w.r.t. dependecy-hell, lack of options to not use stuff, etc.

So let's focus on the dbus dependency here.
Comment 15 Adam Williamson 2012-07-25 17:10:55 EDT
You don't have to remove a package in order not to use it. If you never want to use NM under any circumstances, just mask it. That will prevent it being launched via systemd in any way - dbus activation or otherwise.
Comment 16 Michal Schmidt 2012-07-25 18:36:33 EDT
(In reply to comment #14)
> So let's focus on the dbus dependency here.

I'd prefer to focus on the topic this BZ is about, not on offtopic rants.
Comment 17 Pavel Šimerda (pavlix) 2012-07-26 04:34:47 EDT
> If there's no reason, why was DBus activation added to NM? Why does NM ship
> a DBus service activation file
> (/usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service)?
> 
> Hm, perhaps the reason was to allow DBus clients that want to talk with NM
> to start in parallel with it? In this case supporting the DBus activation
> could serve as an implicit ordering guarantee.

Probably and perhaps it was so that systemd can detect it's actually running. At least this was what Dan told me. I believe we must (and can) get rid of it.
Comment 18 Michal Schmidt 2012-07-26 04:42:06 EDT
(In reply to comment #17)
> Probably and perhaps it was so that systemd can detect it's actually
> running.

No, the detection cannot be influenced by this.

> At least this was what Dan told me. I believe we must (and can) get
> rid of it.

Reassigning to NM then.
Comment 19 Pavel Šimerda (pavlix) 2012-07-26 04:47:45 EDT
> You don't have to remove a package in order not to use it. If you never want to
> use NM under any circumstances, just mask it. That will prevent it being
> launched via systemd in any way - dbus activation or otherwise.

This is a good tip to cover a small subset of use cases.

But, this report is about something else. We should at least make sure we agree about the basic things.

0) NetworkManager is a system service to configure networking

1) Most people want NM to start on boot, those who don't, probably expect
'disable' to do what they want. They can then manually start NM when they
see fit. (This is how chkconfig off always worked for them.)

2) Some people want to stop NM (so that it is started on next boot or
manually) and will expect 'stop' to do this for them. (This is how
service always worked for them.)

3) Some people may want to block NM altogether. They can use 'mask' for this
so they don't need to remove execute bit from the binary (as I used to do).

4) Some services depend on NetworkManager and/or want to start 'after' it.

I guess (3) would work right away and (4) can be done by a separate program
nm-online that waits for NM busname to show up (even if that's pretty ugly).

Then (2) could be probably fixed by removing all the bus activation stuff and dbus-systemd integration from NetworkManager-originated configs. Then (1) would
probably work.

Is it correct? Is it the best way to do that? I guess we at NetworkManager could
make use of a little help even if the problem is in our configs.
Comment 20 Michal Schmidt 2012-07-26 07:20:04 EDT
(In reply to comment #19)
> We should at least make sure we agree about the basic things.
> 
> 0) NetworkManager is a system service to configure networking
>
> 1) Most people want NM to start on boot, those who don't, probably expect
> 'disable' to do what they want. They can then manually start NM when they
> see fit. (This is how chkconfig off always worked for them.)

I agree with the above. And I add that "systemctl disable NetworkManager.service" ensures that that NM will be started neither on boot nor by DBus activation.

> 2) Some people want to stop NM (so that it is started on next boot or
> manually) and will expect 'stop' to do this for them. (This is how
> service always worked for them.)

I agree. I also acknowledge that although "systemctl stop NetworkManager.service" stops the currently running NM, it does not prevent any future DBus activation of NM.

> 3) Some people may want to block NM altogether. They can use 'mask' for this
> so they don't need to remove execute bit from the binary (as I used to do).

I agree.

> 4) Some services depend on NetworkManager and/or want to start 'after' it.
> 
> I guess (3) would work right away and (4) can be done by a separate program
> nm-online that waits for NM busname to show up (even if that's pretty ugly).

I do not think that nm-online is appropriate for all possible services from (4).
I can imagine a service that wants to call NM's DBus APIs regardless of the online state. I do now know if there are any practical examples. Anyway, should NM drop its support for DBus activation, the possible recommendations for this kind of services would be:
 a) Do not assume NM is always running. It may come and go at any time.
    Deal with it.
 b) Use After=NetworkManager.service

> Then (2) could be probably fixed by removing all the bus activation stuff
> and dbus-systemd integration from NetworkManager-originated configs. Then
> (1) would probably work.

Only (2) needs fixing. (1) already works.

> Is it correct? Is it the best way to do that? I guess we at NetworkManager
> could make use of a little help even if the problem is in our configs.

1. Remove the file
   /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service
2. Remove this line from /usr/lib/systemd/system/NetworkManager.service:
   Alias=dbus-org.freedesktop.NetworkManager.service
3. Using an appropriate rpm scriptlet, remove this symlink on upgrades from
   previous versions:
   /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service

See if anything breaks.
Comment 21 Pavel Šimerda (pavlix) 2012-07-26 12:23:40 EDT
> I agree. I also acknowledge that although "systemctl stop
> NetworkManager.service" stops the currently running NM, it does not prevent
> any future DBus activation of NM.

Understood.

> > 4) Some services depend on NetworkManager and/or want to start 'after' it.
> > 
> > I guess (3) would work right away and (4) can be done by a separate program
> > nm-online that waits for NM busname to show up (even if that's pretty ugly).
> 
> I do not think that nm-online is appropriate for all possible services from
> (4).

Good point.

> I can imagine a service that wants to call NM's DBus APIs regardless of the
> online state. I do now know if there are any practical examples. Anyway,
> should NM drop its support for DBus activation, the possible recommendations
> for this kind of services would be:
>  a) Do not assume NM is always running. It may come and go at any time.
>     Deal with it.

Sounds reasonable.

>  b) Use After=NetworkManager.service
> 
> > Then (2) could be probably fixed by removing all the bus activation stuff
> > and dbus-systemd integration from NetworkManager-originated configs. Then
> > (1) would probably work.
> 
> Only (2) needs fixing. (1) already works.

Good.

> > Is it correct? Is it the best way to do that? I guess we at NetworkManager
> > could make use of a little help even if the problem is in our configs.
> 
> 1. Remove the file
>    /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service
> 2. Remove this line from /usr/lib/systemd/system/NetworkManager.service:
>    Alias=dbus-org.freedesktop.NetworkManager.service
> 3. Using an appropriate rpm scriptlet, remove this symlink on upgrades from
>    previous versions:
>    /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service
> 
> See if anything breaks.

Thanks a lot!
Comment 22 Jirka Klimes 2012-09-06 08:27:35 EDT
*** Bug 801370 has been marked as a duplicate of this bug. ***
Comment 23 udo 2012-11-23 05:46:52 EST
NM does not work for me. (usb0 with changing HW address does not exist according to NM author; yet it runs Linux; no fix in sight and this is just one of the issues)
NM cannot be disabled properly due to this bug.
NM cannot be properly removed due to dependency hell with control panel. (why? ever thought of a more modular setup?)
So who is going to fix NM anytime soon?

NM _must_ allow the user to control stuff and /not/ have a mind of it's own.
If these issues show in a wired setup, then what about wifi abusers?
NM _must_ not keep double administrations.
NM _must_ not distrust udev and do udev's work yet again.
Comment 24 Michal Schmidt 2012-11-23 06:17:13 EST
(In reply to comment #23)
> NM cannot be disabled properly due to this bug.

Not true. "systemctl disable NetworkManager.service" disables NM's activation on boot _and_ its DBus activation.

Alternatively, the alias symlink /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service can be removed manually, followed by "systemctl daemon-reload" to take effect. This will disable the DBus activation of NM without affecting the activation of NM on boot.
Comment 25 udo 2012-11-23 06:28:26 EST
Then what is the use of this bug?
Comment 26 Pavel Šimerda (pavlix) 2012-11-23 14:26:56 EST
(In reply to comment #24)
> Not true. "systemctl disable NetworkManager.service" disables NM's
> activation on boot _and_ its DBus activation.

This is all nice but doesn't help the most basic use that is stopping a daemon
so that it stays stopped.

The current temporary solution is in other software. No other software should attempt to activate NM via D-Bus. There is no reason to do that.

> Alternatively, the alias symlink
> /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service can be
> removed manually, followed by "systemctl daemon-reload" to take effect. This
> will disable the DBus activation of NM without affecting the activation of
> NM on boot.

Even though we merged some changes to systemd unit file, the following
change (source: opensuse patches) has been rejected:

commit db70a2c914ac9424e49ec66e78f1227af5dbcde4
Author: Pavel Šimerda <psimerda@redhat.com>
Date:   Wed Sep 5 21:01:50 2012 +0200

    REJECTED: systemd: avoid D-Bus in NetworkManager.service
    
    Inspired by openSUSE patches, this change should help avoid unwanted
    NetworkManager starts.
    
    REJECTED by dcbw because of concerns about systemd dependencies. OpenSUSE,
    though, is using it already.

diff --git a/data/NetworkManager.service.in b/data/NetworkManager.service.in
index 9a5f125..2c73df7 100644
--- a/data/NetworkManager.service.in
+++ b/data/NetworkManager.service.in
@@ -15,6 +15,4 @@ StandardError=null
 
 [Install]
 WantedBy=multi-user.target
-Alias=dbus-org.freedesktop.NetworkManager.service
 Also=NetworkManager-wait-online.service
-
diff --git a/data/org.freedesktop.NetworkManager.service.in b/data/org.freedesktop.NetworkManager.service.in
index 5bd091b..a10126b 100644
--- a/data/org.freedesktop.NetworkManager.service.in
+++ b/data/org.freedesktop.NetworkManager.service.in
@@ -8,4 +8,3 @@
 Name=org.freedesktop.NetworkManager
 Exec=/bin/false
 User=root
-SystemdService=dbus-org.freedesktop.NetworkManager.service


(In reply to comment #25)
> Then what is the use of this bug?

It could probably be closed as WONTFIX or something, as other software must behave nicely to neutralize this problem.
Comment 27 Michal Schmidt 2012-11-23 16:15:26 EST
(In reply to comment #26)
>     REJECTED by dcbw because of concerns about systemd dependencies.

Did this happen in a public mailing list or Bugzilla? I'd like to read the argument myself.
Comment 28 Pavel Šimerda (pavlix) 2012-11-26 07:12:12 EST
(In reply to comment #27)
> (In reply to comment #26)
> >     REJECTED by dcbw because of concerns about systemd dependencies.
> 
> Did this happen in a public mailing list or Bugzilla? I'd like to read the
> argument myself.

I'm afraid it was only on IRC. We reviewed quite a bit set of commits and did
not have enough time to discuss this particular one. I kept it in case we
want to discuss it more thoroughly later.

I'll poke dcbw about this bug report so it can be resolved in any way, with or without modification of the systemd unit.
Comment 29 udo 2012-11-26 07:20:23 EST
Do we have a graphic representation of the correlation and interoperation(s) between systemd, dbus, NM and possibly more things?
This could help us to understand what needs to be done where to get rid of whatever problem.
Bug numbers can be annotated there as well.
Comment 30 Marko Myllynen 2012-11-28 08:38:22 EST
(In reply to comment #24)
> (In reply to comment #23)
> > NM cannot be disabled properly due to this bug.
> 
> Not true. "systemctl disable NetworkManager.service" disables NM's
> activation on boot _and_ its DBus activation.

On a freshly installed F18 Beta using all-defaults and logging in via GDM this is what happens on gnome-terminal:

[testuser@localhost ~]$ date
Wed Nov 28 15:17:49 EET 2012
[testuser@localhost ~]$ su -
Password: 
[root@localhost ~]# ip addr show p3p1 | grep "inet "
    inet 10.160.108.188/23 brd 10.160.109.255 scope global p3p1
[root@localhost ~]# systemctl stop NetworkManager.service
[root@localhost ~]# ip addr show p3p1 | grep "inet "
    inet 10.160.108.188/23 brd 10.160.109.255 scope global p3p1
[root@localhost ~]# systemctl stop network.service
[root@localhost ~]# ip addr show p3p1 | grep "inet "
    inet 10.160.108.188/23 brd 10.160.109.255 scope global p3p1
[root@localhost ~]# systemctl disable NetworkManager.service
rm '/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service'
rm '/etc/systemd/system/multi-user.target.wants/NetworkManager.service'
rm '/etc/systemd/system/network.target.wants/NetworkManager-wait-online.service'
[root@localhost ~]# systemctl disable network.service
network.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig network off
[root@localhost ~]# systemctl stop NetworkManager.service
[root@localhost ~]# systemctl stop network.service
[root@localhost ~]# ip addr show p3p1 | grep "inet "
    inet 10.160.108.188/23 brd 10.160.109.255 scope global p3p1
[root@localhost ~]# date
Wed Nov 28 15:21:00 EET 2012
[root@localhost ~]# 

I'll attach output from journalctl -f during these commands.

Please provide a simple method for the superuser to disable networking at will.

Thanks.
Comment 31 Marko Myllynen 2012-11-28 08:38:59 EST
Created attachment 653545 [details]
journal-log.txt
Comment 32 Michal Schmidt 2012-11-28 09:00:09 EST
Marko,
the log shows that NM was not reactivated again after you disabled and stopped it. This just confirms what I said.
You are still seeing an IP address assigned to the interface because NM does not take interfaces down on quit. As far as I know, this is intentional. After NM quits, the interfaces are unmanaged and you can ifconfig them down as you like. Whether that's good or bad behaviour, it is not related to the issue discussed in this BZ.
Comment 33 Marko Myllynen 2012-11-28 09:20:24 EST
(In reply to comment #32)
> You are still seeing an IP address assigned to the interface because NM does
> not take interfaces down on quit. As far as I know, this is intentional.
> After NM quits, the interfaces are unmanaged and you can ifconfig them down
> as you like. Whether that's good or bad behaviour, it is not related to the
> issue discussed in this BZ.

Right, so in addition to the previous steps the superuser needs to loop over the network interfaces (lo, eth0, wlan0, p3p1, br0, vnet0, etc) to make sure networking is taken down.
Comment 34 udo 2012-11-28 09:42:59 EST
`service network stop`

Worked very well and better than NM.
Check the usb0 issue.
Check the dependencies.
But can I now get confirmed that one issue is out of the air now? (the dbus start issue)
Comment 35 Pavel Šimerda (pavlix) 2012-11-28 12:30:13 EST
(In reply to comment #30)
> [root@localhost ~]# ip addr show p3p1 | grep "inet "
>     inet 10.160.108.188/23 brd 10.160.109.255 scope global p3p1

This is not a test whether NetworkManager is running or not. Currently,
stopping NetworkManager has nothing to do with cleaning up the network
interfaces.

> I'll attach output from journalctl -f during these commands.
> 
> Please provide a simple method for the superuser to disable networking at
> will.

This is not as easy as one might think and is not the topic of this bug report. If
you insist on having a feature to clean up all network configuration, please file
a new bug report (better upstream than Fedora) so that we can discuss the
possibilities.

Currently, stopping NetworkManager means stopping the daemon, stopping all daemons
it launched while leaving as much of the configuration as possible still working.
Comment 36 Dan Williams 2012-11-28 13:37:21 EST
So what is the actual bug here now?  This is clearly no longer about the title (Even though NetworkManager was stopped manually, it gets restarted automatically) because that issue is only a systemd issue, and the systemd guys do not want to change anything there.  If we remove the D-Bus activation alias, then we also increase startup time because systemd cannot parallelize things that want to talk to NetworkManager.  I consider this issue a systemd bug, not a NetworkManager one, but a bug that upstream system does not want to fix.

So if there's another issue here, lets rename the bug at least.

udo: there are some future changes coming that will help your usb0 changing MAC address issue, but that should be another bug not this one.
Comment 37 Marko Myllynen 2012-11-29 05:04:42 EST
(In reply to comment #30)
> Please provide a simple method for the superuser to disable networking at
> will.

FWIW, I filed https://bugzilla.redhat.com/show_bug.cgi?id=881665 about this.

Thanks.
Comment 38 Dan Williams 2012-12-06 18:48:46 EST
(In reply to comment #27)
> (In reply to comment #26)
> >     REJECTED by dcbw because of concerns about systemd dependencies.
> 
> Did this happen in a public mailing list or Bugzilla? I'd like to read the
> argument myself.

It happened via IRC conversations after I talked to the systemd people, for a few reasons:

1) removing the dbus service tag from the NM system file prevents parallelization of startup, potentially slowing down startup speed for services that want to talk to NetworkManager

2) in almost all instances, NetworkManager does not get stopped for long periods of time.  The cases where it does, the user is (a) advanced and (b) doing something specific to the system, and that's not a general use-case.  I also dislike this auto-start behavior of systemd, but I'm going to live with it because the only cases where it annoys me are when I'm developing NetworkManager and that's clearly not something that many users do.  In fact, less than 30 people probably develop NetworkManager, and clearly an order of magnitude more than that use NetworkManager but don't develop the core daemon directly.  So I choose to live with this limitation of systemd.

In your case, you are stopping NetworkManager because you want to do some bridged networking that NetworkManager does not support (yet).  So the solution here is to turn off NetworkManager entirely, using:

systemctl mask NetworkManager
systemctl stop NetworkManager

and boom, NM will no longer be restarted.  Obviously, the old 'service' command did both of those in the same command, but systemd does not, and now you need two commands to do the same thing.
Comment 39 Dan Williams 2012-12-06 18:55:12 EST
Basically, we won't be changing the NM unit file.  If you want the behavior to change, please fight with the systemd people for a command that both stops *and* masks the unit, or something like that.  I've moved it to systemd in case you want to re-open the bug and do that.
Comment 40 Pavel Šimerda (pavlix) 2012-12-06 20:43:57 EST
(In reply to comment #38)
> 2) in almost all instances, NetworkManager does not get stopped for long
> periods of time.  The cases where it does, the user is (a) advanced and (b)
> doing something specific to the system, and that's not a general use-case. 
> I also dislike this auto-start behavior of systemd,

With Michal Schmidt's help, I concluded that the restart's are not done by systemd but through D-Bus activation. That means something asks for NetworkManager start.

Tell me, Dan, couldn't D-Bus activation be blocked by the D-Bus rules?

> but I'm going to live
> with it because the only cases where it annoys me are when I'm developing
> NetworkManager and that's clearly not something that many users do.  In
> fact, less than 30 people probably develop NetworkManager, and clearly an
> order of magnitude more than that use NetworkManager but don't develop the
> core daemon directly.  So I choose to live with this limitation of systemd.
> 
> In your case, you are stopping NetworkManager because you want to do some
> bridged networking that NetworkManager does not support (yet).  So the
> solution here is to turn off NetworkManager entirely, using:
> 
> systemctl mask NetworkManager
> systemctl stop NetworkManager

This is not needed unless something in the systems performs D-Bus activation of NetworkManager. The current Fedora 17's Gnome Shell no longer does that. On systems without this problem, the following should be enough:

service NetworkManager disable
service NetworkManager stop

Or, if you like systemctl's undue verbosity:

systemctl disable NetworkManager.service
systemctl stop NetworkManager.service

The 'mask' action is only a workaround for the D-Bus activation problem.

> and boom, NM will no longer be restarted.  Obviously, the old 'service'
> command did both of those in the same command, but systemd does not, and now
> you need two commands to do the same thing.

I always remember calling two commands, 'service ... stop' and 'chkconfig ... off'.

That means systemd is not the offender here, even though that time on IRC, nobody was really helpful. But that only means people still haven't learned systemd just as we haven't.
Comment 41 Pavel Šimerda (pavlix) 2013-01-03 18:53:57 EST
This already worked correctly in Fedora 17, I thought this was because gnome shell stopped dbus-activating NetworkManager. But now I realised NetworkManager gets restarted after 'service NetworkManager stop' in Fedora 18.

I don't know what has changed and whether now the problem is in systemd or whatever, but this is a problem.
Comment 42 Dan Winship 2013-01-04 10:05:12 EST
(In reply to comment #41)
> This already worked correctly in Fedora 17, I thought this was because gnome
> shell stopped dbus-activating NetworkManager.

I don't think it was ever fixed in F17. The dbus-activation happens because of something in libnm-glib (I forget what), not anything gnome-shell was explicitly doing.
Comment 43 Stefan Hellermann 2013-01-05 15:47:40 EST
why do I have to mask the service? From the systemd homepage [1]:

"You can disable a service. This unhooks a service from its activation triggers. That means, that depending on your service it will no longer be activated on boot, by socket or bus activation or by hardware plug (or any other trigger that applies to it)."

So if I disable NetworkManager it should not be started by whatever mechanism beside "systemctl start NetworkManager.service". This is my user point of view.

I noticed a similar problem while stoping and disabling wpa_supplicant.
sudo systemctl disable wpa_supplicant.service
sudo systemctl stop wpa_supplicant.service

and after a few seconds it was running again!



[1] http://0pointer.de/blog/projects/three-levels-of-off.html
Comment 44 Pavel Šimerda (pavlix) 2013-01-05 20:17:22 EST
(In reply to comment #42)
> (In reply to comment #41)
> > This already worked correctly in Fedora 17, I thought this was because gnome
> > shell stopped dbus-activating NetworkManager.
> 
> I don't think it was ever fixed in F17. The dbus-activation happens because
> of something in libnm-glib (I forget what), not anything gnome-shell was
> explicitly doing.

The spurious restarts never happen for me in F17. But I have no explanation for that. If you believe that this is in libnm-glib, I'd be happy for more information. If you believe it is in libnm-glib, please reassign.

(In reply to comment #43)
> You can disable a service.

It has been already discussed, including the source you link to. The use case for stopping a service is different from the use case of disabling a service. Masking is not a solution, and disabling neither.

The use case:

Administrator wants the NetworkManager service to be removed from running services but *not* removed from services activated on boot (and equivalents like target activation).

This was typically done by 'service NetworkManager stop'. Unless the administrator explicitly asks systemd to do something, the service is not expected to be started again.

We never agreed who is the offending process that request the start of NetworkManager and how. Dan Winship suggests it is in NetworkManager library. If so, then it should be easy to fix for us. But then I'm curious why I don't see the restarts in F17 but I do see it in F18.
Comment 45 Dan Winship 2013-01-07 12:20:43 EST
(In reply to comment #44)
> > I don't think it was ever fixed in F17. The dbus-activation happens because
> > of something in libnm-glib (I forget what), not anything gnome-shell was
> > explicitly doing.
> 
> The spurious restarts never happen for me in F17. But I have no explanation
> for that. If you believe that this is in libnm-glib, I'd be happy for more
> information. If you believe it is in libnm-glib, please reassign.

Hm. Well, I meant "it happens because of something libnm-glib does, but it's not really libnm-glib's fault", but now that I think about it a little more, that's not true; the default behavior of a D-Bus method call is to autostart the service if it's not already running, so libnm-glib (specifically nm_secret_agent_register() in this case, according to comment 2) *is* asking for NM to be autostarted, so systemd is doing the right thing (and the old solution of Exec=/bin/false was basically just cheating on our part).

There's a "no auto start" flag, but it looks like you can't set it when making the call via dbus-glib. (You can from gdbus). But alternatively, NMSecretManager could just track whether or not NM is running, like NMClient and NMRemoteSettings do, and not make calls to it if it's not.

So, yeah, let's move this bug back to NM.

(Actually, probably the "track whether or not NM is running" code should be split out into a new object rather than duplicating it in NMClient, NMRemoteSettings, and NMSecretManager.)
Comment 46 udo 2013-01-07 12:33:23 EST
Was the original problem fixed?
(NM destriying a perfectly working network config)
The workaround is disabling NM which still doesn't work well if I read coreectly.
Third option, which also doesn't really work as desired is completely uninstalling NM but due to dependency hell (ever heard of making stuff truly modular?!!) that is not a complete possibility.

So the source is in the design of NM and the plan of the developer(s) of NM.
They don't understand what we need.

The workaround doesn't work because it was never ever considered to be a desire to disable something 100%. (same for e.g. PackageKit, it has no off button)

The real solution doesn't work for similar reasons as reason two.

I propopose to kill F18 ASAP and fix the real issues before unleashing another load of unfixable  problems upon us.
I know it should be out by now but please show some responsibility.

Now what can we test w.r.t. the root cause?
Now what can we test w.r.t. the workaround?
Now what can we test w.r.t. the real solution (removal)?
Comment 47 Dan Winship 2013-01-07 12:56:52 EST
(In reply to comment #46)
> The workaround is disabling NM which still doesn't work well if I read
> coreectly.

Yes, which is why this bug is still open. The previous comment explains how the bug will be fixed.
Comment 48 udo 2013-01-07 13:04:34 EST
The root cause need to be fixed as well!
What else does the NM developer do?
What about the uninstall case? That also needs a fix.
We don't need NM in all cases so better no install it.
That saves energy, CPU, bandwidth, etc.

So fixing the workaround is not enough.
Comment 49 Dan Winship 2013-01-07 13:08:19 EST
This bug report is "Even though NetworkManager was manually stopped, it gets restarted automatically via D-Bus". The other things you mention are not part of this bug.
Comment 50 udo 2013-01-07 22:29:34 EST
Sure, stick to the 'rules' instead to progress.
I will see if I can find another example of NM destroying a perfectly working network setup. and re-open that one and/or open a new bug for the modularity.

Thanks.
Comment 51 Pavel Šimerda (pavlix) 2013-01-08 07:56:45 EST
(In reply to comment #48)
> So fixing the workaround is not enough.

The original report is ambiguous. As the report was already closed and I reopened it because NetworkManager is started when it shouldn't be, please consider this bug report being strictly about malfunctioning service management (NM being started when it should not).

Doing otherwise would only cause confusion.

(In reply to comment #50)
> I will see if I can find another example of NM destroying a perfectly
> working network setup. and re-open that one and/or open a new bug for the
> modularity.

Yes, this is an important QA task. When you have something, please open a new bug report in the upstream bugzilla (http://bugzilla.gnome.org/). Upstream is a better place to discuss issues like that one.

What more, NetworkManager in Fedora is usually run the whole time. The original bug report is about what happens with manually configured connections when NM is started and nobody really cares unless the disconnection is fatal (e.g. NFS boot). Another +1 for moving it upstream where it is possible to track such subtle issues.
Comment 52 Pavel Šimerda (pavlix) 2013-01-17 11:58:26 EST
*** Bug 896639 has been marked as a duplicate of this bug. ***
Comment 53 Pavel Šimerda (pavlix) 2013-01-17 12:34:17 EST
(In reply to comment #26)
> (In reply to comment #24)
> commit db70a2c914ac9424e49ec66e78f1227af5dbcde4
> Author: Pavel Šimerda <psimerda@redhat.com>
> Date:   Wed Sep 5 21:01:50 2012 +0200
> 
>     REJECTED: systemd: avoid D-Bus in NetworkManager.service
>     
>     Inspired by openSUSE patches, this change should help avoid unwanted
>     NetworkManager starts.
>     
>     REJECTED by dcbw because of concerns about systemd dependencies.
> OpenSUSE,
>     though, is using it already.
> 
> diff --git a/data/NetworkManager.service.in b/data/NetworkManager.service.in
> index 9a5f125..2c73df7 100644
> --- a/data/NetworkManager.service.in
> +++ b/data/NetworkManager.service.in
> @@ -15,6 +15,4 @@ StandardError=null
>  
>  [Install]
>  WantedBy=multi-user.target
> -Alias=dbus-org.freedesktop.NetworkManager.service
>  Also=NetworkManager-wait-online.service
> -
> diff --git a/data/org.freedesktop.NetworkManager.service.in
> b/data/org.freedesktop.NetworkManager.service.in
> index 5bd091b..a10126b 100644
> --- a/data/org.freedesktop.NetworkManager.service.in
> +++ b/data/org.freedesktop.NetworkManager.service.in
> @@ -8,4 +8,3 @@
>  Name=org.freedesktop.NetworkManager
>  Exec=/bin/false
>  User=root
> -SystemdService=dbus-org.freedesktop.NetworkManager.service
> 
> 

Solution also confirmed by:

https://bbs.archlinux.org/viewtopic.php?pid=1207260

That doesn't mean that it is or isn't a good idea, just that people tend to use it.
Comment 54 udo 2013-01-17 12:44:26 EST
It _is_ a good idea.
Every package (set of packages) needs an ON/OFF button and a way to completely uninstall that (set of) package(s).

Many, many fedora components lack both.
There's dependency-hell for no good reason, there's config files that lack the 'shut up' feature.

So this is no rant, just a general rule that very well fits NM.
(as well as PK, etc)
Comment 55 Dan Winship 2013-01-17 14:00:25 EST
please do not rant. it is not helpful
Comment 56 Pavel Šimerda (pavlix) 2013-02-07 09:16:55 EST
Just curious whether it would be possible to deny dbus activation to non-root users and whether it would help to mitigate this problem or not.
Comment 57 Dan Winship 2013-02-08 12:57:40 EST
(In reply to comment #45)
> But alternatively,
> NMSecretManager could just track whether or not NM is running, like NMClient
> and NMRemoteSettings do, and not make calls to it if it's not.

This turns out to be easy to do (NMSecretManager is actually already tracking this), but it doesn't fix the problem; something else causes NM to be activated even after making NMSecretManager not do it. (In fact, at the moment, it seems to be the case that if you stop NM from within gnome-shell, it *immediately* gets restarted.)
Comment 58 Dan Williams 2013-04-02 15:15:58 EDT
(In reply to comment #57)
> (In reply to comment #45)
> > But alternatively,
> > NMSecretManager could just track whether or not NM is running, like NMClient
> > and NMRemoteSettings do, and not make calls to it if it's not.
> 
> This turns out to be easy to do (NMSecretManager is actually already
> tracking this), but it doesn't fix the problem; something else causes NM to
> be activated even after making NMSecretManager not do it. (In fact, at the
> moment, it seems to be the case that if you stop NM from within gnome-shell,
> it *immediately* gets restarted.)

I'm pretty sure I've made this change in the dcbw/private-bus branch.  There's actually a couple of places that libnm-glib would poke NetworkManager that I've eliminated in the dcbw/private-bus branch.

To be clear: nothing in libnm-glib should send NetworkManager any message whatsoever if NetworkManager is not present on the bus.  Otherwise it's a bug we need to fix.
Comment 59 Dan Williams 2013-04-02 15:19:18 EDT
(In reply to comment #56)
> Just curious whether it would be possible to deny dbus activation to
> non-root users and whether it would help to mitigate this problem or not.

I think I've said before in this bug or on IRC, I forget... but lets just remove the dbus activation stuff altogether and take the possible start parallelization hit.

I still believe, at the core, this is a systemd bug.  If the administrator forces a service to stop, that indicates that the administrator does not want the service restarted until they say themselves it should be restarted, regardless of what else on the system wants the service autostarted.

But since nobody seems to want to fix the problem at the source, I'm fine to remove the autostart bits from NetworkManager, where they only exist to allow startup parallelization.  They are not intended to allow NM to be autostarted, and the NM developers have never intended NM to be dbus autostarted since about 2006.
Comment 60 Michal Schmidt 2013-04-03 07:40:45 EDT
(In reply to comment #59)
> nobody seems to want to fix the problem [in systemd]

Not sure if you saw my comments in bug 909134 (a clone of this one) where I considered some related improvements in systemd.
Comment 61 Pavel Šimerda (pavlix) 2013-04-04 09:34:59 EDT
(In reply to comment #59)
> But since nobody seems to want to fix the problem at the source, I'm fine to
> remove the autostart bits from NetworkManager, where they only exist to
> allow startup parallelization.

Since we have the information from Michal that I admit I either missed or forgot, I'm curious whether it's possible to get this any further with systemd.

What do you think should be done for now? Should we fix it for now or wait for systemd? I'm interested in Michal's opinion, too.

> They are not intended to allow NM to be
> autostarted, and the NM developers have never intended NM to be dbus
> autostarted since about 2006.

If systemd is modified to conditionally block dbus activation, should we use this new feature, or should we disable the dbus activation anyway?
Comment 62 Dan Williams 2013-08-26 18:09:40 EDT
So latest update is that if we disable dbus activation for NetworkManager to make people happy that it's not auto-spawned, then instead of just making things slower at startup, it can actually cause services that use NM's d-bus interface to *fail*, because they can no longer start up in parallel with NM and wait on NM's dbus socket to be ready, and they will just fail instead of waiting.

In the end, NM was never intended to be dbus-activated.  We've tried to prevent that through NM dbus and system configuration, but this is apparently a moving target and I'm tired of tracking it.  I have no idea what NetworkManager is supposed to do in the dbus and systemd configuration to prevent dbus activation but still allow parallel startup, so I'm just going to close this and let systemd deal with the issue of services that shouldn't be activated after the administrator has stopped them.
Comment 63 Pavel Šimerda (pavlix) 2013-08-30 17:55:37 EDT
For the record, if this bug gets ever reopened, there are two known solutions to do this issue:

1) systemd should start to respect the administrator's will and keep track of administratively stopped services and avoid autostarting them.

2) NetworkManager should stop using dbus socket activation and the systemd unit and/or the should be modified to *wait* for NetworkManager to create the socket (e.g. by NetworkManager notifying systemd about its startup progress).

The first one would also solve problems with a number of other socket-activated services while the latter one would only help NetworkManager.
Comment 64 Karel Volný 2013-12-06 07:04:32 EST
(In reply to Pavel Šimerda from comment #63)
> 1) systemd should start to respect the administrator's will and keep track
> of administratively stopped services and avoid autostarting them.

let's try ... bug #1039023

*** This bug has been marked as a duplicate of bug 1039023 ***

Note You need to log in before you can comment on or make changes to this bug.