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:
You could always add your own custom target. IMO it's not a bug. Elad Alfassa, Not a systemd developer.
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.
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.
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
(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.
It can be D-Bus activated, and it seems enabled by default: [Install] WantedBy=multi-user.target Alias=dbus-org.freedesktop.NetworkManager.service
Right, which has: [D-BUS Service] Name=org.freedesktop.NetworkManager Exec=/bin/false User=root SystemdService=dbus-org.freedesktop.NetworkManager.service
(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.
(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
(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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is this still a bug or did the solution Michal proposed in comment 3 suffice and this can be closed?
I tried Michal's script from #3 and it still brings up the network when trying to boot with that :(
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.
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
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
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.