Bug 708537
Summary: | RFE: softer version of "systemctl isolate" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill C. Riemers <briemers> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | amcnabb, fred, harald, johannbg, johannbg, jsynacek, kc8hfi, lnykryn, lpoetter, metherid, mrmazda, mschmidt, plautrba, rvokal, stanley.king, tmraz, udovdh, zbyszek |
Target Milestone: | --- | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-29 10:01:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 784611 |
Description
Bill C. Riemers
2011-05-27 21:30:22 UTC
This is likely an issue with the plymouth service files. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. '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. 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. 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. (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. *** Bug 752875 has been marked as a duplicate of this bug. *** Out of curiosity, is this considered a high-priority issue? 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. (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. systemctl switch-to $foo.target that is equivalent to what people expect when switching runlevels would solve this problem neatly *** Bug 787230 has been marked as a duplicate of this bug. *** 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". 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. 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 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. 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. 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. *** Bug 1190488 has been marked as a duplicate of this bug. *** 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. (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.....! 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. 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. 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. 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... I agree that the best solution may be to remove the misleading compatibility behavior. (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`. (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 (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 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. (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 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? (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 ). 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... (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. 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. (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. (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. 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. (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. (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. 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. This bugreport has taken FIVE years. comment #39 showed sufficient understanding of the issue. So what has changed that it is a mess now? Jan, I don't think the report is a mess--it's just been ignored. But I guess "WONTFIX" applies either way. :) |