Bug 615293 - starts NetworkManager even though the admin turned it off
Summary: starts NetworkManager even though the admin turned it off
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
: 619934 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-16 12:06 UTC by Michal Schmidt
Modified: 2010-08-09 15:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-09 15:16:07 UTC
Type: ---

Attachments (Terms of Use)
do not add Wants for SysV Provides (1.08 KB, patch)
2010-08-01 13:00 UTC, Michal Schmidt
no flags Details | Diff

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:
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):

How reproducible:

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:


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.

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