Description of problem: This is from 'man telinit': 2, 3, 4, 5 Change the SysV runlevel. This is translated into an activation request for runlevel2.target, runlevel3.target, ... and is equivalent to systemctl start runlevel2.target, systemctl start runlevel3.target, ... In reality after booting to, say, runlevel 3 a command 'telinit 5' is not doing anything which I was able to notice. Replacing that with 'systemctl start runlevel5.target' does not change anything. Well, maybe not entirely true. 'runlevel' command now prints "4 5". ??? Similarly when on level 5 after 'telinit 3' graphic login is still going strong and does not show any signs of going away. Some things do work. 'telinit 0' actually powers off a machine and 'telinit 6' reboots. 'telinit 1' does start some "switch-off" activities but it is hard to tell what are real results because all consoles are also going away making this "rescue mode" rather useless and even dangerous if there is real trouble where one would want to avoid powering down a machine (but there is not much choice afterwards). Option '--no-wall' is supposed to prevent sending wall message before reboot/halt/power-off. In some sense it "works" as I did not notice really any messages of that sort even if '--no-wall' was not used. Version-Release number of selected component (if applicable): systemd-7-3.fc14.x86_64 How reproducible: always Expected results: telinit really switches runlevels and wall message are issued when appropriate unless explicitely turned off. Additional info: telinit is doing level switching when 'init=/sbin/upstart' is used
Booting in 3 and "init 5" is my usual routine so I can confirm this. One way to make it work that I've found is to "systemctl stop getty" before "init 5". This from tty2 or more of course.
(In reply to comment #1) > One way to make it work that I've found is to "systemctl stop > getty" before "init 5". This from tty2 or more of course. This indeed appears to work if one want to go from level 3 to level 5. 'runlevel' prints "4 5" for a change and a graphic login starts. OTOH my attempts to go back to level 3 all failed. Even "systemctl stop graphical.target" does not look like stopping anything and 'runlevel' still shows "4 5" does not matter what and gdm process is still present.
Created attachment 440793 [details] dmesg with systemd.log_level=debug I booted into runlevel 3, then attempted 'init 5'. The problem was reproduced. Attached is the debug log. Some interesting parts: init[1]: Trying to enqueue job graphical.target/start init[1]: Added job graphical.target/start to transaction. [...] init[1]: Added job plymouth-quit.service/start to transaction. init[1]: Added job prefdm.service/stop to transaction. [...] init[1]: Added job prefdm.service/start to transaction. init[1]: Added job getty/stop to transaction. init[1]: Added job plymouth-quit.service/stop to transaction. init[1]: getty/stop would stop a running service. init[1]: Deleting getty/stop to minimize impact. init[1]: Deleting job prefdm.service/start as dependency of job getty/stop
The man page was actually wrang, it should suggest "systemctl isolate", not "systemctl start". This is fixed now upstream. Hmm, the main issue though is not fixed yet. Not sure how to do this best. systemd is actually smarter here than it should be, and minimizes the transaction more than the user intended.
I can confirm in F14 using systemctl isolate multiuser.target . Booting with single kernel parameter then systemctl isolate graphical.target works as expected.
The main issue is still not fixed in systemd 8.
Created attachment 441440 [details] systemd 8.1 - isolatemulti.user.target from graphical.target Further testing of latest systemd 8.1 update. Problem persists.
*** Bug 625409 has been marked as a duplicate of this bug. ***
This is now fixed upstream.
systemd-9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-2.fc14
The scenario from comment 1 still doesn't work for me after updating to systemd-9-2.fc14
I confirm systemd-9.2 does NOT fix the bug. The "minimize impact" still kicks in. The debug log looks exactly the same as in comment #3.
Clarification: When booted into runlevel 3, "systemctl isolate graphical.target" starts prefdm correctly. But "init 5" or "telinit 5" do not.
"telinit" is in fact a symlink to "systemctl". "telinit 5" is processed by src/systemctl.c:start_unit() with arg_action==ACTION_RULEVEL5. It gets into the else branch (line 1250): assert(arg_action < ELEMENTSOF(table)); assert(table[arg_action]); method = "StartUnit"; mode = (arg_action == ACTION_EMERGENCY || arg_action == ACTION_RESCUE) ? "isolate" : "replace"; The mode is passed to start_unit_one(). What is the intended difference between "isolate" and "replace"? Why isn't a runlevel change request always mapped to mode "isolate"?
systemd-9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-3.fc14, initscripts-9.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.18-1.fc14
This is a behaviour observed with systemd-9-3.fc15.x86_64: 1. 'telinit 5' and 'telinit 3' do not make an impression that they even try to do something. 2. 'telinit 1' kills the whole system in a short order requiring a power switch. 'systemctl isolate rescue.target' has the same effect. 3. 'systemctl isolate runleve5.target' does take a system to level 5 but in the process it kills apparently permanently a console on which this command was typed. This is NOT that one on which X is now running. 4. 'systemctl isolate runlevel3.target' appears to work when started in level 5. 5. 'systemctl isolate emergency.target' gets down to something which appears to be equivalent to a single user mode only this is a one-way street. All attempts to restore a normal system operation ('systemctl default', 'systemctl isolate multiuser.target', and similar) end up with attempts to fsck already mounted file systems and after that one is dropped into "(Repair filesystem)" shell where an exit restarts the same loop with no obvious way out save a reboot. The "best" I got here was the following (modulo transcription mistypes) error message: init[1]: systemd-initctl socket failed to listen on sockets: File exists After that the system was dead.
I agree with previous comment. In my opinion switching runlevels wasn't fixed properly. If you try different switching from 5 to 3, from 1 to 2 and so on, there are dead ends. Testcase 1: init 1 -> correct, now init 2. Dead end, you can only switching consoles, but keyboard doesn't work. Same with telinit. Testcase 2: systemctl isolate runlevel3.target -> ok. Now systemctl isolate runlevel2.target Transaction order is cyclic. See system logs: init[1] : prefdm.service still around after SIGKILL, Entering failed mode. init[1] : Unit prefdm.service entered failed state. Let's see which runlevel are we really running: # runlevel 5 3 How is this possible? The switching between runlevels doesn't work well. I'm not familiar with isolate, but there should be stated whether both or one of these commands will be supported and what we have to use.
*** Bug 631018 has been marked as a duplicate of this bug. ***
After booting to runlevel 5, logging in ans issuing a telinit 1 command, X got killed and I was dumped at a hsell prompt, OK so far. However runlevel reports it's still in 5 and networking is still up, though none of the getty's work. So it's kind of in single user mode, but not fully. Running telinit 5 from there does bring back X. Booting into single user mode from grub works as expected. When in X (runlevel 5), telinit 3, doesn't seem to do anything. When in runlevel 1, telinit 3 works as expected.
(In reply to comment #20) > After booting to runlevel 5, logging in ans issuing a telinit 1 command, X got > killed and I was dumped at a hsell prompt, Which versions of systemd and initscripts was that? It is difficult to compare observations otherwise.
initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
*** Bug 631734 has been marked as a duplicate of this bug. ***
It is getting certainly better but not there yet: systemd-9-3.fc15.x86_64 and initscripts-9.19-1.fc15.x86_64. (BTW - is somebody testing a basic sanity of that, beyond "it happened to boot", before dropping results on an "unsuspecting public"?). Booting into a single user mode does work; as well typing 'telinit 1' and 'telinit s' from levels 3 and 5. The catch is that on which console one get a shell prompt is a guessing game and it may be necessary to hit <Return> a few times before something will react. Also the following error messages: D-Bus activation failed for dbus-org.freedesktop.NetworkManager.service: Invalid argument are showing up many times during each of those operations. Switching levels invariably kills getty on various vt's. Although some may be restored by switching levels again mingetty on tty1 looks like a permanent loss. What is "eating" that is kind of mystery. It is gone even without X running and anyway X shows up on vt7. 'telinit 5' from level 3 looks like it is doing its job. OTOH 'telinit 3' when on level 5 it has no discernible effect. That despite that 'systemctl isolate multi-user.target' or 'systemctl isolate runlevel3.target' bring a system down to level 3. Maybe this is a sideffect of that that once at level 5 and output from 'runlevel' is invariably "3 5" - regardless to what target a system was switched. During shutdown and reboot gdm is terminated and comes back five or six times. Somewhat weird, visibly slows down the whole operation and is likely not healthy if you are trying to track down at least some problems with X server.
'unsuspecting public'? It's only going into Rawhide (which is Rawhide) and Fedora 14 (which hasn't even hit beta yet). Anyone running either can hardly be described as 'unsuspecting'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Your shutdown and reboot issues, at least, are likely fixed with initscripts-9.20-1.
(In reply to comment #25) > 'unsuspecting public'? It's only going into Rawhide Do you need triple quotes to recognize a jest? Still some initial "sanity" testing would be nice.
(In reply to comment #26) > Your shutdown and reboot issues, at least, are likely fixed with > initscripts-9.20-1. Sorry! On that long description of a state I forgot to mention that explicitely. These issues indeed look like fixed.
"Do you need triple quotes to recognize a jest?" On the internet, frequently, yes.
*** Bug 632899 has been marked as a duplicate of this bug. ***
Joining in on this one. Appears telinit 3 (does nothing) in runlevel 5 still doesn't work and the only workaround is the systemctl isolate command. After that runlevel correctly says "5 3". I also noted the system always starts on runlevel 5 even though /etc/inittab says it should start with 3. Maybe this is related? initscripts-9.20-1.fc14 systemd-9-3.fc14 Nothing newer in updates-testing so far that I could find.
(In reply to comment #31) > I also noted the system always starts on runlevel 5 even though > /etc/inittab says it should start with 3. This part is not a bug. systemd is controlled by /etc/systemd/system/default.target, not /etc/inittab. The comment in inittab should be changed to reflect this - that's tracked in bug 627474.
I am trying to figure out which issues listed here still remain with the current dbus, current initscripts, current systemd. It's difficult to distill this from the various comments especially given that many of these issues are now fixed with the recent initscripts upload. - telinit 3 from runlevel 5 does not work but "systemctl isolate runlevel3.target" does. - telinit 3 from runlevel 5 does not spawn a getty on tty1. - when switching between runlevels 3 and 5 gettys on the other ttys are restarted I extracted that from Michal J's last comment. Michal, did I miss anything? A few additional notes: - It is not a bug that the default runlevel mentioned in /etc/inittab is not honoured. See comment #32. - It is not a bug that when you switch to runlevel 4 the "runlevel" command will tell you your are in "5". Because by both runlevels are identical in systemd with the defualt configuration, the response "4" and "5" are equally correct. The runlevel command will however return "5" since traditionally on Fedora 4 is not used and 5 is equivalent to it. In fact with the default config "runlevel" should only ever show you one of S 3 5. - Due to the paralelization the single-user mode shell might get obfuscated by other output. Press enter or so to get a redrawn prompt. - "D-Bus activation failed for dbus-org.freedesktop.NetworkManager.service: Invalid argument" is only shown in debug mode now.
(In reply to comment #33) . > > - telinit 3 from runlevel 5 does not work but "systemctl isolate > runlevel3.target" does. > > - telinit 3 from runlevel 5 does not spawn a getty on tty1. > > - when switching between runlevels 3 and 5 gettys on the other ttys are > restarted > > I extracted that from Michal J's last comment. Michal, did I miss anything? Yes, two things. One that I started that comment 24 noting explictity that I am talking about systemd-9-3.fc15.x86_64 and initscripts-9.19-1.fc15.x86_64 which are still current for rawhide as of today. Two is about "does not spawn a getty on tty1". I possibly was not clear enough here. This is not about 3 -> 5 transition. If you will do that while booted into a single user mode then getty on tty1 goes away too; permanently. I could not figure out why as tty1 does not look like "special" in the whole configuration. Apparently this happens with other level transitions although I did not possibly look at every combination. getty may vanish on other vt's as well but another level switch will likely restore it except of this special case. > In fact with the default config > "runlevel" should only ever show you one of S 3 5. AFAICT an output from "runlevel" is always "3 5" does not matter what an actual state (yes, two numbers separated by a space and not one or another). At least after you once got into level 5. That was explicitely noted in comment 24. Makes runlevel aware scripts somewhat difficult. A suggestion was that maybe this has something to do with telinit troubles but I do not know that. > - "D-Bus activation failed for dbus-org.freedesktop.NetworkManager.service: > Invalid argument" is only shown in debug mode now. Maybe rawhide is by a default in a debug mode? At this moment I do not even know how to switch here debug on or off.
The issue with telinit 3 not having the same effect as "systemctl isolate runlevel3.target" is now fixed in git. Note that tty1 is special, since that is where we call X11. prefdm.service conflicts getty to make sure it doesn't have to fight for the tty. My guess is that there is a simple ordering dep between prefdm.service and the getty missing, so that we make sure that the getty is killed first and only then X started, and vice versa. I have now added this to git too, but this must be copied to initscripts.
Lennart, I can confirm all your points except for the restarting ttys. I've got systemd-9-3.fc14.x86_64 and initscripts-9.20-1.fc14.x86_64 installed. For me, any ttys I'm logged into remain, except for tty1 (when changing from 3 to 5 with "systemctl isolate runlevel5.target") which appears to be simply killed -- by design it seems -- so I only have tty2 - tty6 in an usable state (even though X starts on virtual console 7, but I doubt that's got anything to do with systemd).
(In reply to comment #35) > > Note that tty1 is special, since that is where we call X11. prefdm.service The catch is that X is running on vt7. I looked at processes. Also getty on tty1 does not go away only on level 5. That would be expected with X on vt1 instead of vt7. It disappears permanently does not matter on which level you happen to be and that means that you better not to try to reduce a number of spawned gettys.
My systemd v10 upload from yesterday should fix the main issues, except for the problem that getty on tty1 is not restarted when you switch from runlevel 5 to runlevel 3. For now I hope this enough for the F14Beta to be dropped from the bug.
For me it works satisfactorily now. gdm starts on entering runlevel 5 and quits on going to runlevel 3. It works with "systemctl isolate" and "telinit". The missing getty@tty1 after a runlevel switch should not be a blocker.
With systemd-10-2.fc14 telinit seems to be working how I expect it to. Sweet.
I'm assuming this is fixed in Rawhide's systemd, Lennart. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers