Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: softer version of "systemctl isolate"|
|Product:||[Fedora] Fedora||Reporter:||Bill C. Riemers <briemers>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||amcnabb, fred, harald, johannbg, johannbg, jsynacek, kc8hfi, lnykryn, lpoetter, metherid, mrmazda, mschmidt, plautrba, rvokal, stanley.king, tmraz, udovdh, zbyszek|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-01-29 05:01:05 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Bill C. Riemers 2011-05-27 17:30:22 EDT
Description of problem: Due to docking problems, I frequently need to drop to a console window and drop from run level 5 to run level 3 and back again. Once and a while I accidentally switch to the run level I'm already running. e.g. Run level 5 to run level 5. The new systemd initialization switches to a splash image display when switching run levels so I cannot see what is happening. Unlike during the initial boot, I cannot find a key that takes me back to the console. So when switching from run level 5 to run level 5 it stops right at the end and never restarts my display. The laptop won't respond to any of my key sequences so eventually I just have to resort to powering down and restarting. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot to run level 5. 2. Switch to a virtual console, say CTRL+ALT+F2 3. Login as root. 4. Type 'init 5'. Actual results: Splash image appears showing progress until just a sliver of black is showing, then freezes. Expected results: There is nothing to do, I'm already at run level 5, it should just be a do nothing command. When the splash screen is shown, pressing escape should allow me to see the log, and I should be able to use other keys to switch between virtual consoles. Additional info: I really hate having to cold power boot like this. I suppose I could try starting a second computer and connecting via ssh to see if I can at least do a clean shutdown.
Comment 1 Bill Nottingham 2011-05-31 13:03:32 EDT
This is likely an issue with the plymouth service files.
Comment 2 Fedora Admin XMLRPC Client 2011-10-20 12:27:42 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 3 Michal Schmidt 2011-11-18 11:10:08 EST
'init 5' translates into 'systemctl isolate graphical.target'. Isolate does more than people expect: - Services that are not obviously pulled in by the new target will be killed. This includes services that are usually loaded on-demand, including the stdout-syslog-bridge, which the processes connected to it won't like. The getty units are also affected by this now that they're autospawned. - Oneshot units that have completed successfully before, but don't have RemainAfterExit=yes, will be re-run again. This can affect the plymouth problem. So the isolate action is brutal and not really what's expected from runlevel switching. We should not fix isolate, because it is useful in itself, but there should be a new action, say "systemctl approach $foo.target". systemd would remember the last approached target and when asked to approach another one, it would compare the set C of units pulled by the current target with the set N of units pulled by the new target. It would stop only units in C-N, it would start units in N-C. It is obvious that switching from runlevel 5 to 5 would then be a NOP.
Comment 4 Andrew McNabb 2011-11-18 12:41:16 EST
I can see how isolate might be helpful in some situations, but it's certainly not what's expected for changing runlevels. I have noticed that switching runlevels kills all open login sessions on VTs. In other words, if I'm logged in on tty3 and switch to a different runlevel with "init 3" or "init 5", then I get automatically logged out. By the way, the systemctl(1) man page states, "This is similar to changing the runlevel in a traditional init system", which is false.
Comment 5 Bill C. Riemers 2011-11-18 13:19:59 EST
For me this was fixed by one of the updates of Fedora 15. I'm now on Fedora 16 which also does not have the problem.
Comment 6 Andrew McNabb 2011-11-18 14:43:18 EST
(In reply to comment #5) > For me this was fixed by one of the updates of Fedora 15. I'm now on Fedora 16 > which also does not have the problem. You may not have deadlocking anymore, but switching runlevels still doesn't behave correctly. For example, note that you get logged out from VTs when you switch runlevels.
Comment 7 Michal Schmidt 2011-12-13 21:31:11 EST
*** Bug 752875 has been marked as a duplicate of this bug. ***
Comment 8 Andrew McNabb 2011-12-14 11:56:53 EST
Out of curiosity, is this considered a high-priority issue?
Comment 9 Bill C. Riemers 2011-12-20 12:24:15 EST
It probably isn't just an issue of isolating actions. Classically, switch from say runlevel 5 to runlevel 3 would kill the X11 session, which in turn killed all the applications running under X. You'll find in Fedora 16 this isn't quite what happens. The X session is killed, but processing running under X still continue. So if you switch back to run level 5, login again, you won't be able to start things like Thunderbird, because Thunderbird is still running. I don't have a proposal as how to fix it, just the observation that what happens today is not very usable. The other thing I find strange is that things that should just continue running, are stopped and restarted. The example in comment #6 is a great one. Why should your virtual sessions be killed, when this service is valid for both the original run level and the new run level? I take it that part of this is because the new system tries to keep track of dependencies... Traditionally, I could but up a unix like system at say run level 2, and then cleanly step to run level 3, and then run level 5, and expect with the average configuration each step more services would be started, and none would be restarted. While this presented some problems, when people picked illogical assignment of services to run levels, the new process seems to create a whole new class of problems that are not even well understood yet.
Comment 10 Michal Schmidt 2011-12-21 19:44:49 EST
(In reply to comment #9) > It probably isn't just an issue of isolating actions. Classically, switch from > say runlevel 5 to runlevel 3 would kill the X11 session, which in turn killed > all the applications running under X. You'll find in Fedora 16 this isn't > quite what happens. The X session is killed, but processing running under X > still continue. That's not what I'm seeing. My X sessions are killed thoroughly. > The other thing I find strange is that things that should just continue > running, are stopped and restarted. I believe I explained this in comment #3.
Comment 11 Rahul Sundaram 2011-12-22 17:11:42 EST
systemctl switch-to $foo.target that is equivalent to what people expect when switching runlevels would solve this problem neatly
Comment 12 Michal Schmidt 2012-02-03 11:38:42 EST
*** Bug 787230 has been marked as a duplicate of this bug. ***
Comment 13 Lukáš Nykrýn 2012-06-21 10:28:10 EDT
I don't think that we need other function to switch between runlevels. Isolate behaves the same way as runlevel change in older inits. The only issue which was here was killing for example getty on tty3, but this is not fault of isolate, but getty's service file, in upstart there were tty1-6 running permanently and this is solved by "IgnoreOnIsolate=yes".
Comment 14 Michal Schmidt 2012-06-21 10:52:15 EDT
No, the killing of getty is not the only issue, though it was the most visible one. I mentioned other issues in comment #3. And I consider "IgnoreOnIsolate=yes" for getty a workaround, not a fix.
Comment 15 Fedora End Of Life 2013-01-16 12:41:15 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 16 Fedora End Of Life 2013-12-21 03:27:58 EST
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Comment 17 Zbigniew Jędrzejewski-Szmek 2014-06-22 17:05:13 EDT
Currently 'init 3' will kill all sorts of things pseudo-randomly: - cups.service, because it is socket activated, and only the sockets are WantedBy/RequiredBy multi-user.target - various hardware activated things - user sessions IMO, the idea of using 'systemctl isolate m-u.target' as a replacement for 'init 3' is completely broken. I don't think anyone is going to implement a new replacement command like comment #3 suggests, because less and less people care about sysv command compatibility and it would be useful mostly just for that. So... I propose to: - make 'init 3' do 'systemctl start runlevel-3.target' and likewise for other init levels - make gdm.service Conflict with multi-user.target, and likewise for other graphical login managers This will make 'init 3' kill graphical session, and 'init 5' start it if it wasn't started yet. If in runlevel 3, aka multi-user.target, systemctl start gdm.service will stop the target, which won't really do much, since stopping the target only stops StopWhenUnneeded=true services, and start gdm. This should give us behaviour which is more useful and less surprising.
Comment 18 Zbigniew Jędrzejewski-Szmek 2014-06-22 19:36:37 EDT
Well... Apparently 'systemctl start multi-user.target' causes gdm.service to be stopped (without any explicit conflicts between them yet). Why? Because plymouth-quit.service is WantedBy multi-user.target, and gdm.service conflicts with plymouth-quit.service. By chance this does what I wanted in this case, but seems rather bizzare. If I add 'my.service' with Wants=multi-user.target, and start it, gdm.service will be stopped. This seems wrong. Plymouth integration seems to be an endless source of crazy hard-to-debug errors. Maybe it should be redesigned.
Comment 19 Zbigniew Jędrzejewski-Szmek 2015-02-09 09:15:10 EST
*** Bug 1190488 has been marked as a duplicate of this bug. ***
Comment 20 udo 2015-02-09 09:20:17 EST
RFE? We replace the original init because of whatever, we offer `init 3` as a compatibility feature yet is is not compatible. This is a bug and needs a fix soon as it is core functionality.
Comment 21 udo 2015-02-09 09:22:41 EST
(In reply to Andrew McNabb from comment #8) > Out of curiosity, is this considered a high-priority issue? I guess so. Yet four years pass. (In reply to Rahul Sundaram from comment #11) > systemctl switch-to $foo.target that is equivalent to what people expect > when switching runlevels would solve this problem neatly I guess so.....!
Comment 22 udo 2015-02-09 09:56:57 EST
For the readers of this bug that might have missed the bug that was closed as duplicate; from the manual page: 2, 3, 4, 5 Boot into the specified legacy SysV runlevel. These are equivalent to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target, systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target, respectively, and provided for compatibility reasons and to be easier to type. Please note the word 'compatibility'. As you may have grasped I perceive the `init 3` behaviour not at 'compatible'. I perceive init compatibility as core functionality. In this light this bug needs a quick fix.
Comment 23 Jóhann B. Guðmundsson 2015-02-09 10:43:48 EST
The concept of runlevel does not apply to systemd and as such there are no runlevels in systemd. It has it's own concepts of targets which may or may not be boot targets and as such the "backwards compatibility" to the concept of "run levels" is limited. Just be glad that there exist backwards compatibility to the concept of runlevels in some form. It could be non existing or removed altogether if it comes down to it. And please do not fiddle with the severity level of bugs on reports since the severity level on reports are used internally by developers to organize their own workload not for you to demand higher preference on how they spend their *free* time fixing *your* bugs. Thanks.
Comment 24 udo 2015-02-09 10:55:11 EST
I did not ask for systemd. I did not ask for chages to `init 3`. I did not program systemd. So it is not my bug. I am astonished by the lack of speed and the lack of understanding for core functionalities. If that is your stance towards bugs, functionalities and 'progress' you may resign right now. No thanks as systemd has brought me more bugs than init ever did. So please fix as requested.
Comment 25 Bill C. Riemers 2015-02-09 15:20:13 EST
Of course most of have long since learned how to do our normal work with systemd. Really the main "bug" here as far as I'm concerned is that systemd includes what looks like the old style tools that works completely different. It might be a quick and easy solution just to remove the "init" command all together. Then there would be no confusion...
Comment 26 Andrew McNabb 2015-02-09 15:54:35 EST
I agree that the best solution may be to remove the misleading compatibility behavior.
Comment 27 udo 2015-02-09 22:34:00 EST
(In reply to Andrew McNabb from comment #26) > I agree that the best solution may be to remove the misleading compatibility > behavior. And we should learn the systemd equivalent command line for `init 3`.
Comment 28 Jóhann B. Guðmundsson 2015-02-10 04:24:40 EST
(In reply to udo from comment #27) > (In reply to Andrew McNabb from comment #26) > > I agree that the best solution may be to remove the misleading compatibility > > behavior. > > And we should learn the systemd equivalent command line for `init 3`. Right and here's the compatibility list which maps which run levels to systemd targets runlevel0.target --> poweroff.target runlevel1.target, rescue.target runlevel2.target, multi-user.target runlevel3.target, multi-user.target runlevel4.target, multi-user.target runlevel5.target, graphical.target runlevel6.target, reboot.target So the command equal lent to init 3 is "systemctl isolate multi-user.target" If you dont like what gets start you can write your own boot.target and change the targets like so systemctl isolate <your custom boot>.target You list targets like systemctl list-units --type target --all You can view the default target systemctl get-default Set the default target systemctl set-default name.target You switch to emergency or rescue mode with wallboard message like so systemctl rescue systemctl emergency You switch to emergency or rescue mode without wallboard message like so systemctl --no-wall rescue etc... Read the docs
Comment 29 Jóhann B. Guðmundsson 2015-02-10 04:40:49 EST
(In reply to Bill C. Riemers from comment #25) > Of course most of have long since learned how to do our normal work with > systemd. Really the main "bug" here as far as I'm concerned is that systemd > includes what looks like the old style tools that works completely > different. It might be a quick and easy solution just to remove the "init" > command all together. Then there would be no confusion... We cant consider starting to removing legacy cruff until at least everything in the distribution has been migrated to the new init system and that work has been halted ( the daemon/service as well as relevant cron to timer jobs )due to certain Red Hat employees thinking they are smarted then the individual(s) that had been digging in the dirt and doing all that work and since they claimed to be experts on the matter they were asked to put their money where their mouth was and just do it themselves and that has not happened for well over a year now and is clear never will at this point unless they learn to keep their mouth shut and stop harassing people that are doing that work. Once that has been completed Red Hat's internal political battle begins due to Fedora's direction being governed and crippled not only by RHEL but also CentOS these days. ( for example /etc/sysconfig/foo environmental files for services/daemon since they are no longer relevant to daemon/service startup ) And once Red Hat employees have stopped playing game of moans internally then finally you can go through relevant processes in Fedora along with necessary guidelines changes from FPC which literally can take years. So expect 3 - 5 years passing before that wish has an remote chance becoming reality
Comment 30 udo 2015-02-10 10:11:22 EST
Please let me know what to type to go from the graphical `target` to the multi user `target` by killing just(!) the Xorg-related processes, whenever that option becomes available.
Comment 31 Jóhann B. Guðmundsson 2015-02-10 10:42:02 EST
(In reply to udo from comment #30) > Please let me know what to type to go from the graphical `target` to the > multi user `target` by killing just(!) the Xorg-related processes, whenever > that option becomes available. As I mentioned before create your own custom boot target with whatever behavior you want and run systemctl isolate <your custom boot>.target
Comment 32 udo 2015-02-10 10:52:30 EST
It boots into the graphical target. But Perhaps I'd like to take it the multi user target sometime. Is the keyword 'isolate'? Or what is the exact difference with the `init 3` implementation that is offered?
Comment 33 Jóhann B. Guðmundsson 2015-02-10 11:41:48 EST
(In reply to udo from comment #32) > It boots into the graphical target. > But Perhaps I'd like to take it the multi user target sometime. > Is the keyword 'isolate'? > Or what is the exact difference with the `init 3` implementation that is > offered? What and how other type units get started is what you decide when creating your own custom boot target so the difference with the multi-user.target is what you make of it. See Michal's comment 3 for further explanation of what ( might ) happen ( it depends on type units being used in relevant target being isolated to ).
Comment 34 udo 2015-02-10 11:48:42 EST
So if comment 3 is the sane wording of what I expect from an `init 3` equivalent in systemd-speak, what time will it take to implement such command? The formulation is from 2011...
Comment 35 Jóhann B. Guðmundsson 2015-02-10 12:01:49 EST
(In reply to udo from comment #34) > So if comment 3 is the sane wording of what I expect from an `init 3` > equivalent in systemd-speak, what time will it take to implement such > command? > The formulation is from 2011... I dont see the point of implementing another command. What I gather is needed from the original description from Bill C. Riemers on this report is simply ensure that systemctl isolate is not allowed to isolate to $current target so you cannot for example do systemctl isolate graphical.target if you are already in the graphical.target ( he runs init 5 from within in init 5 and init 5 == graphical.target ) and systemctl isolate should error out with something like "cannot isolate to current target" If you want a different behavior from the provided targets you have to write your own custom target and use that instead.
Comment 36 udo 2015-02-10 12:09:37 EST
In that case `my` bug was not a duplicate. I do not want the `init 3` (when in runlevel 5) kill more than just the Xorg-related stuff. This is sorta like the 'isolate' line but should not involve plymouth and other stuff that already ran. See https://bugzilla.redhat.com/show_bug.cgi?id=708537#c3 It appears my choice of behaviour is not doable in current systemd. I think I guess I need the command as described at https://bugzilla.redhat.com/show_bug.cgi?id=708537#c3. THat description allows for more than just the runlevel 5; init 5 issue.
Comment 37 Jóhann B. Guðmundsson 2015-02-10 13:03:31 EST
(In reply to udo from comment #36) > In that case `my` bug was not a duplicate. > I do not want the `init 3` (when in runlevel 5) kill more than just the > Xorg-related stuff. > This is sorta like the 'isolate' line but should not involve plymouth and > other stuff that already ran. See > https://bugzilla.redhat.com/show_bug.cgi?id=708537#c3 > It appears my choice of behaviour is not doable in current systemd. > I think I guess I need the command as described at > https://bugzilla.redhat.com/show_bug.cgi?id=708537#c3. > THat description allows for more than just the runlevel 5; init 5 issue. When I isolate I expect the exact environments and behavior and type units running and having run as I would have booted directly into that isolated target. No more no less. You however seem to be expecting units already run in a different target to be still running after you isolate to another target. If you want that behaviour you need to create custom target with whatever you want to survive between isolation and add "IgnoreOnIsolate=yes" to those units.
Comment 38 udo 2015-02-11 02:36:38 EST
(In reply to Jóhann B. Guðmundsson from comment #37) > (In reply to udo from comment #36) > You however seem to be expecting units already run in a different target to > be still running after you isolate to another target. ? I just want to kill Xorg when going from 5 -> 3 (or rather from graphical to multi user). I do not want to kill or start additional processes. That was what I read from comment 3. It signified a difference from the isolate 'behaviour'. I do not want to tinker with units; that was not necesary at all during SysV init. chkconfig, ntsysv etc were my friends.
Comment 39 Michal Schmidt 2015-02-11 04:06:44 EST
Jóhann, udo, please stop adding more comments to this BZ. The systemd developers have sufficient understanding of the issue. The topic was briefly discussed a week ago in Brno before DevConf.cz.
Comment 40 Zbigniew Jędrzejewski-Szmek 2015-02-12 22:38:28 EST
(In reply to udo from comment #38) > I just want to kill Xorg when going from 5 -> 3 (or rather from graphical to > multi user). "systemctl stop gdm" should do exactly this.
Comment 41 udo 2015-04-04 11:15:47 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #40) > (In reply to udo from comment #38) > > I just want to kill Xorg when going from 5 -> 3 (or rather from graphical to > > multi user). > "systemctl stop gdm" should do exactly this. But then `who -r` still shows 5. I guess that is confusing.
Comment 42 Jan Synacek 2016-01-29 05:01:05 EST
This bugreport has become a mess. If anyone feels that anything mentioned here is still worth considering an RFE, please state it *clearly* in a newly filed upstream issue.
Comment 43 udo 2016-01-29 06:30:29 EST
This bugreport has taken FIVE years. comment #39 showed sufficient understanding of the issue. So what has changed that it is a mess now?
Comment 44 Andrew McNabb 2016-01-29 09:48:58 EST
Jan, I don't think the report is a mess--it's just been ignored. But I guess "WONTFIX" applies either way. :)