Bug 615293

Summary: starts NetworkManager even though the admin turned it off
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: bruno, lpoetter, metherid, michal, pebolle
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-09 15:16:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
do not add Wants for SysV Provides none

Description Michal Schmidt 2010-07-16 12:06:56 UTC 
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.
Comment 1 Lennart Poettering 2010-07-21 00:58:49 UTC 
This is now fixed upstream. New upload will follow shortly.
Comment 2 Michal Schmidt 2010-08-01 11:56:18 UTC 
Still reproducible with systemd-4.4.fc14
Comment 3 Michal Schmidt 2010-08-01 11:56:38 UTC 
*** Bug 619931 has been marked as a duplicate of this bug. ***
Comment 4 Michal Schmidt 2010-08-01 13:00:35 UTC 
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.
Comment 5 Michal Jaegermann 2010-08-03 20:53:15 UTC 
*** Bug 619934 has been marked as a duplicate of this bug. ***
Comment 6 Lennart Poettering 2010-08-04 00:58:55 UTC 
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?
Comment 7 Michal Schmidt 2010-08-04 11:33:37 UTC 
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.
Comment 8 Michal Jaegermann 2010-08-04 16:24:12 UTC 
(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.
Comment 9 Lennart Poettering 2010-08-09 15:16:07 UTC 
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.