Description of problem: I have NetworkManager disabled. I use the classical "network" service instead: $ chkconfig | grep -i netw NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off This works as expected with upstart, but with systemd both the services are started. (And NM breaks my network bridging configuration when it runs.) I figured out that systemd starts NM because it marks it as: RequiredBy=network.target and this is because the LSB header in /etc/init.d/NetworkManager has: Provides: $network I deleted this provide and after next boot it worked as expected (NM was not started). I believe that network.target should not require both providers of $network in the case where one of them had been previously disabled by the administrator. Version-Release number of selected component (if applicable): systemd-3-3.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. chkconfig NetworkManager off 2. reboot Actual results: NetworkManager is still started. Expected results: NetworkManager should not run.
This is now fixed upstream. New upload will follow shortly.
Still reproducible with systemd-4.4.fc14
*** Bug 619931 has been marked as a duplicate of this bug. ***
Created attachment 435858 [details] do not add Wants for SysV Provides This patch fixes it for me, but I may be missing some side-effects. Lennart, please review.
*** Bug 619934 has been marked as a duplicate of this bug. ***
Michal, that patch should not be necessary, unless there is is at least one S link for nm in /etc/rc?.d/ Could you check that? What does "ls /etc/rc?.d/*NetworkManager" show for you?
No, there aren't any S*NetworkManager links. Only K84NetworkManager links: /etc/rc0.d/K84NetworkManager /etc/rc1.d/K84NetworkManager /etc/rc2.d/K84NetworkManager /etc/rc3.d/K84NetworkManager /etc/rc4.d/K84NetworkManager /etc/rc5.d/K84NetworkManager /etc/rc6.d/K84NetworkManager s->sysv_start_priority is set purely by parsing the chkconfig header in /etc/init.d/NetworkManager: # chkconfig: - 23 84 systemd should not base its decision to start the service on this piece of information.
(In reply to comment #6) > ... unless there is is at least one S > link for nm in /etc/rc?.d/ I do not have any relevant S links and NetworkManager, together with wpa_supplicant, do not start if init=/sbin/upstart is used but they do start with systemd. It is possible to stop that systemd behaviour (thanks, MS) with a removal of "$network" from Provides in /etc/init.d/NetworkManager only likely it is there for a reason. See bug 619934 for additional details.
OK, I commited another fix. This one is hopefully the right one, which only considers a service file enable if at least one actual S link exists. Will upload to f14 soon.