Apparently NetworkManager is shipped with both a native systemd init script and a legacy init script. Running "chkconfig NetworkManager off" seems to disable the systemd script but not the legacy SysV init script. +++ This bug was initially created as a clone of Bug #690292 +++ --- Additional comment from amcnabb on 2011-04-01 15:34:26 EDT --- I upgraded to systemd 22, and this problem is now worse. If I run "chkconfig NetworkManager off", it says "Forwarding request to 'systemctl disable NetworkManager.service'" but then doing "chkconfig --list NetworkManager" shows that it is still enabled. If I run "systemctl disable NetworkManager.service", then "chkconfig --list" still shows that it is enabled. I'm not quite sure what native command should show whether systemd is enabled in systemd; I thought that "systemctl status NetworkManager.service" might do this, but "enabled" or "disabled" doesn't appear anywhere in the output. Anyway, it looks like there is no longer any way to disable NetworkManager.service. --- Additional comment from mschmidt on 2011-04-02 08:57:07 EDT --- (In reply to comment #25) > I'm not quite sure what native command should show whether [NetworkManager] > is enabled in systemd; systemctl is-enabled NetworkManager.service && echo yes In case some of the utilities are misbehaving, please show us the output of: ls /etc/rc?.d/*Net* find /etc/systemd/system -name '*Net*' > Anyway, it looks like there is no longer any way to disable > NetworkManager.service. I think it is in fact disabled, but chkconfig cannot be trusted to show that. Well, what did "systemctl status NetworkManager.service" say? Is NM active or not? --- Additional comment from amcnabb on 2011-04-04 13:23:15 EDT --- (In reply to comment #26) > (In reply to comment #25) > > I'm not quite sure what native command should show whether [NetworkManager] > > is enabled in systemd; > > systemctl is-enabled NetworkManager.service && echo yes It does not print anything, so apparently it's not enabled. > In case some of the utilities are misbehaving, please show us the output of: > ls /etc/rc?.d/*Net* > find /etc/systemd/system -name '*Net*' [root@testvm ~]# ls /etc/rc?.d/*Net* /etc/rc0.d/K84NetworkManager /etc/rc2.d/S23NetworkManager /etc/rc4.d/S23NetworkManager /etc/rc6.d/K84NetworkManager /etc/rc1.d/K84NetworkManager /etc/rc3.d/S23NetworkManager /etc/rc5.d/S23NetworkManager [root@testvm ~]# find /etc/systemd/system -name '*Net*' [root@testvm ~]# > I think it is in fact disabled, but chkconfig cannot be trusted to show that. > Well, what did "systemctl status NetworkManager.service" say? Is NM active or > not? This command, unfortunately, does not include "enabled" or "disabled" anywhere in its output: NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service) Active: inactive (dead) CGroup: name=systemd:/system/NetworkManager.service --- Additional comment from mschmidt on 2011-04-04 15:55:10 EDT --- (In reply to comment #27) > > systemctl is-enabled NetworkManager.service && echo yes > > It does not print anything, so apparently it's not enabled. Yes, the native NetworkManager.service is disabled on your system. > > In case some of the utilities are misbehaving, please show us the output of: > > ls /etc/rc?.d/*Net* > > find /etc/systemd/system -name '*Net*' > > [root@testvm ~]# ls /etc/rc?.d/*Net* > /etc/rc0.d/K84NetworkManager /etc/rc2.d/S23NetworkManager > /etc/rc4.d/S23NetworkManager /etc/rc6.d/K84NetworkManager > /etc/rc1.d/K84NetworkManager /etc/rc3.d/S23NetworkManager > /etc/rc5.d/S23NetworkManager This is why chkconfig reports NM as enabled in runlevels 2, 3, 4, 5. But since the native unit trumps the legacy script, the legacy setting has no effect. Didn't chkconfig print a 3-line warning stressing this point? > [root@testvm ~]# find /etc/systemd/system -name '*Net*' > [root@testvm ~]# This confirms that NetworkManager.service is not enabled, because it is not linked from any of the *.wants directories and neither is there the dbus-org.freedesktop.NetworkManager.service symlink present, so NM cannot even be activated by D-Bus. > > Well, what did "systemctl status NetworkManager.service" say? Is NM active > > or not? > > This command, unfortunately, does not include "enabled" or "disabled" anywhere > in its output: > > NetworkManager.service - Network Manager > Loaded: loaded (/lib/systemd/system/NetworkManager.service) > Active: inactive (dead) > CGroup: name=systemd:/system/NetworkManager.service Right, but what I wanted to have confirmed by this, is that the service is in fact inactive.
(In reply to comment #0) > Apparently NetworkManager is shipped with both a native systemd init script and > a legacy init script. Running "chkconfig NetworkManager off" seems to disable > the systemd script but not the legacy SysV init script. What are the actual bad consequences of this? The service will not be started, which is as expected. "chkconfig --list NetworkManager" warns about the fact that its output is not authoritative: Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overriden by native systemd configuration. NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off
As far as I can tell, NetworkManager is indeed starting, which keeps the /etc/init.d/network script from starting.
I'm going to guess that this may be related to bug 691549.
I was finally able to reinstall my system, and with a clean and up-to-date install, "chkconfig NetworkManager off" is still leaving symlinks in /etc/rc?.d, but NetworkManager is not getting started. I still think it's weird that: 1) /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target but /etc/rc5.d/S* are not getting started, and 2) "chkconfig NetworkManager off" is leaving "S23NetworkManager" links in /etc/rc?.d.
(In reply to comment #4) > I still think it's weird that: > 1) /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target > but /etc/rc5.d/S* are not getting started, and This is by design and documented. From "man systemd": Note that a service unit with a native unit configuration file cannot be started by activating it in the SysV runlevel link farm. > 2) "chkconfig NetworkManager off" is leaving "S23NetworkManager" links in > /etc/rc?.d. Hmm, I guess chkconfig could be patched to remove the legacy links too when redirecting to systemctl, just to reduce confusion. Bill, what do you think?
(In reply to comment #5) > Hmm, I guess chkconfig could be patched to remove the legacy links too when > redirecting to systemctl, just to reduce confusion. It has occurred to me that it absolutely should NOT create the S* links in the opposite case of enabling a native service. That would just bring another kind of confusion and it might uncover subtle bugs (like the one I tried to fix in (http://lists.freedesktop.org/archives/systemd-devel/2011-March/001750.html).
It would also be nice if the output of "systemctl status NetworkManager.service" included the word "enable" if it were enabled and "disable" if it were disabled. This would reduce the temptation to go back to well-known legacy tools to try to figure this out. The only reason that I tried to use chkconfig to see whether or not it was enabled is that I couldn't find this information from "systemctl status".
(In reply to comment #5) > > Hmm, I guess chkconfig could be patched to remove the legacy links too when > redirecting to systemctl, just to reduce confusion. > Bill, what do you think? Right now, chkconfig forwards on enable and disable requests to systemd, but looks in /etc/rc?.d to report status. What if chkconfig forwarded on "--list" to systemd, too? This would add more backwards compatibility, increase consistency, and help administrators figure out what each tool does.
(In reply to comment #8) > Right now, chkconfig forwards on enable and disable requests to systemd, but > looks in /etc/rc?.d to report status. What if chkconfig forwarded on "--list" > to systemd, too? This would add more backwards compatibility, increase > consistency, and help administrators figure out what each tool does. This would require doing a not-exactly-correct mapping of systemd targets to runlevels, to maintain consistent output.
(In reply to comment #5) > > 2) "chkconfig NetworkManager off" is leaving "S23NetworkManager" links in > > /etc/rc?.d. > > Hmm, I guess chkconfig could be patched to remove the legacy links too when > redirecting to systemctl, just to reduce confusion. > Bill, what do you think? The most consistent thing to do would be to flip both systems (sysv and systemd); as you said, that's not what you want.
(In reply to comment #9) > > This would require doing a not-exactly-correct mapping of systemd targets to > runlevels, to maintain consistent output. How about just making "chkconfig --list" throw an error saying that this isn't supported in systemd? It might be preferable to have an error than to have a useless response. In fact, is there any case that the output from "chkconfig --list" could be helpful on a machine with systemd?
It's perfectly useful for scripts that don't have systemd equivalents, so it would need to check each service to see if it's overridden by a systemd equivalent. Could be done.
(In reply to comment #12) > It's perfectly useful for scripts that don't have systemd equivalents, so it > would need to check each service to see if it's overridden by a systemd > equivalent. Could be done. That would be great: only show services that don't have systemd equivalents. I can't speak for anyone else, but this would have helped me a ton in my first few stressful days with systemd.
Hmm, "chkconfig --list" does spit out a big big warning, do we really need more? 8 [lennart@epsilon] ~/projects/systemd (master $)$ chkconfig --list avahi-daemon Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overriden by native systemd configuration. avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
(In reply to comment #14) > Hmm, "chkconfig --list" does spit out a big big warning, do we really need > more? Often a big warning is a sign that something needs to be changed. Especially when it tells you that you may or may not have to ignore information that follows. :) The current warning gives a justification for why some unspecified parts of the output will be incorrect while others are correct, but it doesn't do anything to actually make the output less misleading. If chkconfig --list refused to show any information about services that are overridden by systemd, then the warning could be more succinct and all of the output would actually be correct. And it would also make it more obvious how systemd is using SysV scripts, which helps people learn how to use systemd.
Discussed at the 2011-04-15 blocker review meeting. As the impact of this bug seems to be only 'informational' - everything behaves as intended, but examining chkconfig output or /etc/rcX.d directory contents may be misleading - we reject it as a blocker, it does not seem to hit any blocker criteria. We also reject it as NTH as it does not seem like a good thing to screw with during a freeze period, small return with potential major risk. There is an unfrozen period after Beta release when a fix could land without the need for Blocker or NTH status; if there is no fix in that time, it could then be resolved with a 0-day or post-release update, which would have time for proper testing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 698734 has been marked as a duplicate of this bug. ***
http://git.fedorahosted.org/git/?p=chkconfig.git;a=commitdiff;h=55c0f3e082a3531974f83278fc2c1e0f85897ac1 This makes chkconfig not show anything in --list for services overridden by systemd files; it will still print the warning. Hopefully this will be less confusing.
chkconfig-1.3.52-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/chkconfig-1.3.52-1.fc15
*** Bug 699388 has been marked as a duplicate of this bug. ***
Package chkconfig-1.3.52-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chkconfig-1.3.52-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/chkconfig-1.3.52-1.fc15 then log in and leave karma (feedback).
chkconfig-1.3.52-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.