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.
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.
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.)
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.
(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.
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
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.
(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.
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.
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.
I believe it's a change in behavior in that NM wasn't bus activated before systemd, but I may be misremembering.
There is no reason for NetworkManager to be bus activated.
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?
(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.
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.
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.
(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.
> 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.
(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.
> 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.
(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.
> 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!
*** Bug 801370 has been marked as a duplicate of this bug. ***
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.
(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.
Then what is the use of this bug?
(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> 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.
(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.
(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.
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.
(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.
Created attachment 653545 [details] journal-log.txt
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.
(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.
`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)
(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.
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.
(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.
(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.
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.
(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.
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.
(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.
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
(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.
(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.)
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)?
(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.
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.
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.
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.
(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.
*** Bug 896639 has been marked as a duplicate of this bug. ***
(In reply to comment #26) > (In reply to comment #24) > commit db70a2c914ac9424e49ec66e78f1227af5dbcde4 > Author: Pavel Šimerda <psimerda> > 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.
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)
please do not rant. it is not helpful
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.
(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.)
(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.
(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.
(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.
(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?
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.
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.
(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 ***