Red Hat Bugzilla – Bug 470968
Strange exit/suspend behavior
Last modified: 2014-06-18 04:46:27 EDT
Description of problem: I'm seeing two problems which I suspect are related.
The first problem shows up when I login via a console. Bash is my shell. If I then type exit, the console hangs and never returns to a login prompt.
The second problem shows up when I login under X and start a gnome-terminal running bash. If I type suspend in the window, the terminal hangs.
Version-Release number of selected component (if applicable):
Fedora 10 preview
Steps to Reproduce:
Case 1: The console terminal hangs
Case 2: The gnome terminal hangs
Case 1: The console should exit and provide another login prompt.
Case 2: The shell should respond saying a login shell can't be suspended.
Really strange. I don't have this issue. Can you provide me strace output and/or backtrace? And maybe it can be something with libraries which bash use. What version of ncurses-libs and glibc you have?
The strace of the getty case seems to show that bash exits.
The gnome-terminal case acts differently when being straced. Instead of hanging, typing suspend seems to do nothing, not printing a message, but returning to a prompt.
I'll attached logs for both.
This is a fairly fresh install of Fedora 10 and I've been staying up with updates.
Linux ninja 22.214.171.124-79.fc10.i686 #1 SMP Tue Nov 4 21:56:37 EST 2008 i686 i686 i386 GNU/Linux
This smells sort of like a signal handling sort of issue
Created attachment 323183 [details]
strace of bash running under gnome-terminal
Created attachment 323186 [details]
strace of mingetty running bash
Once I was able to reproduce it, but not any more. Really bash exits and the things hangs up in login.
But suspend issue I can't reproduce. What exactly you mean by "terminal hang"? Sending SIGCONT to bash don't help, I guess?
If I start up a gnome-terminal and type suspend, the terminal window sticks around and remains functional (menus work etc), but my bash shell is no longer waiting for input.
If I do a ps I see that the bash shell is still there. If I send the bash shell a CONT signal, it comes back.
So it appears that the problem there is that it shouldn't be allowing me to suspend, when it isn't a sub shell. I have no idea how it determines whether or not it is a subshell.
I did the latest update from Fedora Rawhide. Now the behaviour of the login under mingetty is different. Typing exit in the shell is now causing that shell to correctly exit and mingetty to request a new login.
That means case1 no longer seems to be a problem,
So the suspend works well. Read man page:
Suspend the execution of this shell until it receives a SIGCONT
signal. When the suspended shell is a background process, it
can be restarted by the fg command. For more information, read
the JOB CONTROL section. The suspend command can not suspend the
login shell. However, when -f option is specified, suspend com-
mand can suspend even login shell. The return status is 0
unless the shell is a login shell and -f is not supplied, or if
job control is not enabled.
And I investigate mingetty/login problem and this looks like upstart doesn't respawn event -> mingetty. It's hard to reproduce, but sometimes it happens. I will try to change component to upstart...
It seems that upstart doesn't respawn event even it has set respawn stanzaz. I can reproduce it by holding down ctrl-C, but this is probably respawning too fast issue.
Created attachment 323427 [details]
For example tty5 event in /etc/event.d.
And I take a look at upstart.ubuntu.com and they are talking about upstart v.5 and in rawhide is 0.3.9
Three comments with the gnome-terminal case:
First, it isn't useful to suspend the primary shell in a gnome-terminal. It leaves you with a non functioning shell. If you really want this behaviour then you might as well send it a STOP signal, since you'll have to send it a CONT anyway. Having it respond this way is a PITA! :)
Second, I think this is a change in behaviour from F9. I'm fairly sure it reported an error.
It sounds like you're saying bash is doing the right thing. Maybe that means gnome-terminal is really the culprit. What should they be doing to avoid suspend working like that?
Could this be more of Bug 450488 perhaps?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
*** Bug 472970 has been marked as a duplicate of this bug. ***
I'm unable to reproduce it in the console, running F10 on x86_64.
Seems to be fixed in F10.
Please reopen if it's not the case.