Bug 743603 - LOST_FEATURE: systemd lacks a multi-user-no-network target/runlevel, like sysv did.
LOST_FEATURE: systemd lacks a multi-user-no-network target/runlevel, like sys...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Unspecified
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-10-05 09:56 EDT by Jes Sorensen
Modified: 2013-03-07 19:50 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-07 19:50:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jes Sorensen 2011-10-05 09:56:40 EDT
Description of problem:
I have just discovered that systemd-units doesn't provide a
multi-user-no-network target, ie. the equivalent to runlevel 2
in the old style scripts.

This is needed if you develop networking or need to test network
setups and need to not have them started up before you are ready.
In addition users are used to having runlevel 2 available.

This is a serious regression from sysvinit, please fix before F16
is released!

Version-Release number of selected component (if applicable):
systemd-units-36-3.fc16.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Elad Alfassa 2011-10-05 10:58:59 EDT
You could always add your own custom target. IMO it's not a bug.

Elad Alfassa,
Not a systemd developer.
Comment 2 Jes Sorensen 2011-10-05 11:03:52 EDT
Elad, hard to do when you are testing a new system that fails to boot.
This worked before, we shouldn't just remove it.

Most definitely a bug.
Comment 3 Michal Schmidt 2011-10-05 13:20:10 EDT
I don't accept the argument that the feature is necessary to make networking development possible. Suppose a system fails to boot because a service other than network is broken. Surely you would not ask for a special runlevel "multi user without $SERVICE_YOU_DEVELOP" to be shipped by default.

Your other point, that people are used to runlevel 2, is more valid. But calling it a serious regression is an overstatement.
It's the same in F15, by the way.

There are other ways to deal with services that break the boot, e.g. booting with "single", the stronger "emergency", and in the worst case "init=/bin/sh".
Kay pointed out "modprobe.blacklist=" to avoid the loading of a broken driver.

Let's say we'll want to emulate the classic runlevel 2. We could add a new multi-user-no-net.target:
  [Unit]
  Description=Multi-user without network
  Requires=multi-user.target
  Conflicts=network.service NetworkManager.service
  AllowIsolate=yes
... and make runlevel2.target point to it.

The approach has one big flaw: NetworkManager can be started by D-Bus activation even if it's not pulled in by the initial transaction. To avoid the activation, the service has to be disabled. And if you're disabling one service, you can disable network.service too, at which point you have no need a different target anymore.
Comment 4 Jes Sorensen 2011-10-05 14:10:36 EDT
Michal,

It is a very valid use-case and I have used it in the past to get around
problems. Just because you dislike it, is not a valid excuse for stating the
argument isn't acceptable.

The other key issue is that it a defacto standard. Users and sysadmins are
used to having runlevel 2, and we shouldn't remove it unless we have very
good reason for doing so (as in, it cannot be provided in a secure way).

It is perfectly feasibly to provide a runlevel 2 equivalent here, and there
is absolutely no excuse for not doing so. Lets not break things just for the
sake of breaking them!

Jes
Comment 5 Bill Nottingham 2011-10-05 14:15:20 EDT
(In reply to comment #3)
> I don't accept the argument that the feature is necessary to make networking
> development possible. Suppose a system fails to boot because a service other
> than network is broken. Surely you would not ask for a special runlevel "multi
> user without $SERVICE_YOU_DEVELOP" to be shipped by default.
> 

> Let's say we'll want to emulate the classic runlevel 2. We could add a new
> multi-user-no-net.target:
>   [Unit]
>   Description=Multi-user without network
>   Requires=multi-user.target
>   Conflicts=network.service NetworkManager.service
>   AllowIsolate=yes
> ... and make runlevel2.target point to it.
> 
> The approach has one big flaw: NetworkManager can be started by D-Bus
> activation even if it's not pulled in by the initial transaction. To avoid the
> activation, the service has to be disabled. And if you're disabling one
> service, you can disable network.service too, at which point you have no need a
> different target anymore.

NM isn't bus activated, IIRC.
Comment 6 Kay Sievers 2011-10-05 14:31:50 EDT
It can be D-Bus activated, and it seems enabled by default:
  [Install]
  WantedBy=multi-user.target
  Alias=dbus-org.freedesktop.NetworkManager.service
Comment 7 Bill Nottingham 2011-10-05 14:35:25 EDT
Right, which has:

[D-BUS Service]
Name=org.freedesktop.NetworkManager
Exec=/bin/false
User=root
SystemdService=dbus-org.freedesktop.NetworkManager.service
Comment 8 Michal Schmidt 2011-10-06 03:18:33 EDT
(In reply to comment #4)
> Just because you dislike it, is not a valid excuse for stating the
> argument isn't acceptable.

Apparently I have to clarify my comment #3. In your description of the problem I read two distinct arguments:
 (1) Without runlevel 2 it is impossible to develop networking.
 (2) People are used to using runlevel 2.
Argument (1) is not acceptable because it is a false statement. I conceded (2).

> It is perfectly feasibly to provide a runlevel 2 equivalent here, and there
> is absolutely no excuse for not doing so.

Well then give multi-user-no-net.target a try a let us know how it works for you.
Comment 9 Elad Alfassa 2011-10-06 13:51:27 EDT
(In reply to comment #7)
> Right, which has:
> 
> [D-BUS Service]
> Name=org.freedesktop.NetworkManager
> Exec=/bin/false
> User=root
> SystemdService=dbus-org.freedesktop.NetworkManager.service

Where exactly? it's not in /lib/systemd/system/NetworkManager.service
Comment 10 Michal Schmidt 2011-10-07 02:48:56 EDT
(In reply to comment #9)
> Where exactly? it's not in /lib/systemd/system/NetworkManager.service

The fragment is from the D-Bus service definition /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service.
It tells dbus-daemon what systemd unit to activate when a D-Bus client wants to talk to NM.
Comment 11 Fedora Admin XMLRPC Client 2011-10-20 12:31:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Jóhann B. Guðmundsson 2012-01-29 09:47:46 EST
Is this still a bug or did the solution Michal proposed in comment 3 suffice and this can be closed?
Comment 13 Jes Sorensen 2012-02-15 09:37:12 EST
I tried Michal's script from #3 and it still brings up the network when
trying to boot with that :(
Comment 14 Michal Schmidt 2012-02-15 10:17:09 EST
The problem is that while systemd initially correctly resolves the Conflicts by deleting the job NetworkManager.service/start, when a D-Bus activation request comes, it wins the conflict and the target is stopped instead.

I'm trying to think of another way to achieve the desired result.
Comment 15 Michal Schmidt 2012-02-15 12:01:09 EST
So it is possible to get that, but it's a kind of a hack.

# cat /etc/systemd/system/network-allowed.target 
[Unit]
Description=Precondition to allow NM to start

# ls -l /etc/systemd/system/multi-user.target.wants/network-allowed.target 
lrwxrwxrwx. 1 root root 25 Feb 15 16:25 /etc/systemd/system/multi-user.target.wants/network-allowed.target -> ../network-allowed.target

# cat /etc/systemd/system/multi-user-no-net.target 
[Unit]
Description=Multi-user without network
Wants=multi-user.target
After=multi-user.target
Conflicts=network.service network-allowed.target
AllowIsolate=yes

# cat /etc/systemd/system/NetworkManager.service 
.include /lib/systemd/system/NetworkManager.service
[Unit]
Requisite=network-allowed.target
Comment 16 Fedora End Of Life 2013-01-16 12:41:38 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Lennart Poettering 2013-03-07 19:50:04 EST
To be honest, I don't think we should reintroduce a multi-user-no-network target. I doubt it this is really that useful, in all our time since F15 we only got one request for it. It's hard to implement (as shown above), and where would this stop? People could ask for m-u-no-bluetooth, m-u-no-virt, and what else. And I am pretty sure I don't even want to start with this game.

I can see this is useful for some people, but I also believe we probably should simply leave this to the users, to create a custom targets for this.

(BTW, as soon as we have kdbus we'll make the name registration something that can be pulled in by targets, thus allowing bus activation to be defined per-target).

Hence, closing.

I hope this makes some sense.

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