Description of problem:
No msgs displayed during shutdown.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. select shutdown or restart from menu
logon screen displays, then nothing
shutdown messages displayed
chvt 1; shutdown -h now makes the messsages show up. Seems to be some kind of VT
Msgs are on vt-7. Hitting alt-F7 after selecting shutdown or restart shows
msgs. So, Rahul is right again.
Hmm. They should be going to /dev/console, which I assume would mean they'd show
So, just to get the datapoints, where are the messages:
- when shutdown is invoked from a terminal
- when shutdown is invoked from a display manager or the logout button in the menu
Also, does the use, or non-use, of rhgb change this?
All test run after gnome desktop settled in. Total of 10 tests.
terminal button tty1 tty2 tty3
-------- ------- ---- ------- ------
rhgb no msgs no msgs MSGS no msgs no msgs
no rhgb no msgs no msgs MSGS no msgs no msgs
Per above CTRL-ALT-F1 to tty1 only showed shutdown messages.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
I did notice this issue after upgrading from F8 to F9.
Not able to see shutdown messages like we had on F8.
Shutdown messages are being sent to whatever VT was active when shutdown began.
But when X dies it switches to whatever VT was running when it started (usually
VT1). A few people complained about this behaviour prior during the F9 devel
cycle but no agreement could be reached of what to do about it.
* Desktop team didn't want users to see the shutdown messages during shutdown.
* Disabling the Auto-Switching of VT back to the previous VT when X dies is
likely to cause other confusion.
We need to see shutdown msgs during testing. There should at least be a
mechanism that facilitates this instead of ctrl-alt-f7. Recently, the desktop
has remained after selecting restart or shutdown from the menu without the
ability to see the msgs. An example: I have a cifs mount that hangs up
waiting for umount (now apparently fixed in F9, but not rawhide). Without the
ability to see this hang, I can't confirm that is the problem.
> * Desktop team didn't want users to see the shutdown messages during shutdown.
I don't really care what the "Desktop team" says (!)
I'm a desktop user, and I want to see the shutdown messages instead of a black
I particularly want to see the messages if there is a problem.
Indeed!~ Desktop == GUI.
As soon as xorg is killed the GUI is gone; the text screen should be visible
with all the shutdown message we are used to.
The desktop users should not be afraid: just as on startup (if they dare press
to see the Details) there will be green OK messages when things go well.
Changing over to F10Target - this doesn't mean that the issue will go unresolved
during F9, simply that it should be resolved by the F10 release. I love the
desktop team to death, but I have to respectfully disagree on this one :)
Shutdown messages should either:
1) Be displayed, or
2) Have a message explaining to the user how to get to them (alt-F7)
I'd like to see one of these two things happen somewhat soon (and I don't really
care which one it is).
A third option, and a better option I think:
3) If the user is not using graphical boot, show them the shutdown messages.
After all, they wanted to see them at startup, let them see them at shutdown.
Quickly displaying shutdown msgs essential for testing during Fedora
The simplest way to solve this is for gdm to pass '-novtswtich' to Xorg ; this
prevents X calling a vt switch when it exits.
*** Bug 434899 has been marked as a duplicate of this bug. ***
*** Bug 439280 has been marked as a duplicate of this bug. ***
The short answer for what's happening here:
- When shutdown is invoked, the messages go to the VT that shutdown was invoked on
- In the case where shutdown is invoked from a graphical display, that's the tty
that gdm/kdm/etc is running on
- Then, the display manager and X exit
- X then switches back to whatever VT it was started from (normally, tty1)
At this point, the shutdown messages are on tty7 or tty8, you're on tty1, and
there is no process that actually knows the relation therein to switch you back
to tty7 to see the messages. Nor is there a process that the display manager can
use when executing shutdown to put the messages on the VT that X will switch to
when it exits.
It is possible to solve it by having X not switch VTs in general. But that's
likely to cause other issues.
Actually I find that I can switch to seeing the messages by doing ctrl alt f6.
Frankly in general I would think that since we are trying to degeek Linux a bit
I would prefer to hide the detailed diagnostic messages, which is what happens.
The problem is that there is no indication of what is going on. My preferred
fix here, and I have played with it and not got it to work, would be to leave
the shutdown the way it is, BUT to then send a message to either all screens or
the main screen (tty1) that shutdown is in progress and to see the details do
ctrl alt f6.
I think that unless there's some fundamental design issue that makes it
impossible to show the shutdown messages automatically (which I find hard to
believe), it should at least exist as an option. It's just aggravating to have
to hit Alt-F7 every single time.
(In reply to comment #20)
> I think that unless there's some fundamental design issue that makes it
> impossible to show the shutdown messages automatically (which I find hard to
> believe), it should at least exist as an option. It's just aggravating to have
> to hit Alt-F7 every single time.
Please see comment #18. You're on one tty without any intrinsic knowledge of the
tty that shutdown was started from.
I'm not knowledgeable in this area, but when shutdown is invoked, why don't the
shutdown messages go to the VT that X was started from (since it's known that X
will immediately switch to that VT)?
shutdown messages go to the tty shutdown was invoked on. gdm invokes shutdown.
gdm does not know what tty X was started from, only the tty that X is currently on.
When X is started, can't the tty it was started from be saved in a file or
otherwise passed so that gdm can access that info?
It seems to me a little like we are trying to make the point the hard way.
How about fixing this with the initscripts. I am not that well versed in
these, BUT I bet someone who is could fix this in a matter of minutes.
Here is the deal as I see it. We should be able to setup a script that
pretends to load something, but really loads nothing. But we then set it to be
off for everything but run level 5 (x windows) and load it last in the series
for this run level. We only do enough during the load to flag it as being
loaded. It does really nothing else.
Then as I understand init scripts under the fancy management system for these,
we can tell the system that if this script has been loaded then it must be
unloaded first. All of the real fun is in the unload or "stop" case. What it
would do is execute a could "echo /dev/tty1"s to give a a blank line to make it
stand out then "echo System shutdown or reboot in progress > /dev/tty1" The add
another blank line.
If desired we could even add an echo line that said how to monitor the progress,
but given the degeeking that we are trying to do to Linux I would think avoiding
this added complexity and confusion to the users would be better.
Any real init script geeks out there?
So this should get fixed for f10. For f10 we're going to
1) switch to vt7 immediately
2) force X to start on vt7 even though vt7 is active
3) potentially start a graphical shutdown screen
Not sure this is a huge issue to fix for F9.
In F8 gdm actually printed "System is shutting down... Please wait." or
something like that before it shutdown.
For "potentially" (point 3) do you mean, show the graphical shutdown screen if
startup messages are not shown?
So ideally we want shutdown to be so fast it doesn't matter. Barring that, if
we have a graphical boot up, then it makes sense to have a graphical shutdown on
a) we want shutdown messages as they were before all this stuff happening. the messages being gone is a BUG.
b) the best/most easy/etc way to present the emssages is in text mode
c) X gets killed as one of the first processes I assume
d) the shutdown speed doesn't matter: info is info (especially if stuff goes wrong)
e) what if we don't shutdown but halt?
f) what if we have an error during the oh so fast shutdown?
Currently we don't see anything so our systems could be shredded to bits by some error in the shutdown process. (no, very realistic it IS!)
Please stop deliberating and please restore the old behvaiour before 'improving' with other features. Please.
I can't imagine getting a shutdown that is fast enough that the current experience would not confuse especially novice users who kind appear to be part of the group we are aiming to have the new versions of fedora be more friendly for. There are just to many things that really need to get done and take time. Certainly the absolute core could be programmed to shutdown very quickly. I assume with a great push and effort that maybe all of the applications that ship with your normal fedora could be made to shutdown in a second or two. But first I wonder if this push would be worth it. It would take a major programming effort, and if a proper shutdown message was used I don't see much benefit from this programming effort. Certainly there are other issues that could use the effort. Second in most cases what will have to be done to get this high speed shut down would be to instead of the current system of issuing necessary shutdown commands and then waiting and insuring they are complete before issuing conflicting commands is to issue them all at once and hope for the best. Not a great way to keep the reliability that Linux has such a hard and well earned reputation for. Third Also there will still be third party projects which will need to do a full and probably slow shut down.
So I think some form of a message about shutting down would be the best thing to plan for. Frankly given the novice user that we are kind of targeting I would like to see a two leveled message system. The default would be a simple "shutting down please wait" message, while the details would still in some manner be available if needed for technical support.
One the other hand it sounds like this one is being put on hold until FC10. I believe that some kind of a text message started with the latest update, but I a not sure. Has anyone else seen this and is it working?
I do think the `novice user` wants some confirmation that the shutdown is indeed progressing well, without errors.
Currently the shutdown is initiated and no further feedback about error or success is given.
The old situation should be restored ASAP, in FC9.
Bigger changes could then go in FC10.
I don't understand why there is no much talk about this.
If I turn off graphical boot (i.e. I want to see the startup messages), then I should also see the shutdown messages too.
Exactly. Let it be a choice.
But it isn't. It has been taken away.
Why? For no good reason.
Why can't they see that this is BAD?
So just to be clear. The F9 behavior is a bug. It wasn't a design decison or anything.
It's just not a bug I'm personally going to have time to fix stacked against my other fedora bugs, feature work, and rhel bugs.
For F10, I think comment 32 has it right. If there's boot messages at boot up then there should be boot messages at shutdown.
Created attachment 321281 [details]
Force switch back to VT active when signal sent
Here's a hackish, but working, solution. When a fatal signal (TERM, PIPE, etc.) is received, gdm-binary stores the current VT. This will be the VT the user is on when they Shutdown/Restart. Just before exiting gdm-binary, and after Xorg has died, switch back to the original VT. This will be where the shutdown messages are.
For upstream, something better should be done, but this should work for all common use cases. I have a scratch build on koji if anyone wants to try it:
Wouldn't this mean if you run 'telinit 3' from within X, you may end up on a blank tty?
Yes, it does, unfortunately. I couldn't think of any way to handle that. I guess I'm sort of assuming that the common case of a user shutting down from GNOME has higher priority than someone running telinit from X (how probably knows how to navigate the VTs anyway).
Ray and Jon probably have a better plan, but my longer term thinking here is:
1. Have GDM always manage/change VTs and always start X on the current VT. That takes the X VT switching behavior out of the problem.
2. Have gnome-session and the greeter call out to GDM for shutdown/restart and fall back to ConsoleKit if the GDM interface isn't available.
3. Have GDM kill the current X sessions and then call out to ConsoleKit for shutdown/restart.
This means that GDM can do the right thing with X and the VTs before shutdown is run by ConsoleKit.
I think that if there is just a message on the screen that says "fedora shutting down" or better being able to determine from the message if it is shutting down or rebooting, that would be fine and better than the old version. Users don't need to see the details. Us techees can find the data if we need them, but if the user just gets something that says something is going on that would fix the problem. Then thisa could go from a bug to a feature.
Sorry, I am halfway between user and techie I guess, but I want to see the old style shutdown messages.
Give the graphic whatever screen to the users. I want to *see* that all goes well, that there are no problems, oopses or other issues on shutdown.
This should be solved in Fedora 10, in any case. Closing as rawhide.
What's the solution in rawhide? Just force gdm to use tty1?
That's what ends up solving the effect.
More specifically, it's 'have X/gdm running on the same tty that it's started from'
Sorry, am I missing something here?
If rhgb is enabled, and I shutdown, then I don't want to see any shutdown messages.
If rhgb is not enabled, and I shutdown, I want to see shutdown messages.