Red Hat Bugzilla – Bug 471571
Strange suspend behavior
Last modified: 2014-01-12 19:08:03 EST
+++ This bug was initially created as a clone of Bug #470968 +++
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.
--- Additional comment from email@example.com on 2008-11-11 05:34:50 EDT ---
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?
--- Additional comment from firstname.lastname@example.org on 2008-11-11 10:43:17 EDT ---
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 188.8.131.52-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
--- Additional comment from email@example.com on 2008-11-11 10:46:45 EDT ---
Created an attachment (id=323183)
strace of bash running under mingetty
--- Additional comment from firstname.lastname@example.org on 2008-11-11 10:56:08 EDT ---
Created an attachment (id=323186)
strace of mingetty running bash
--- Additional comment from email@example.com on 2008-11-12 06:38:48 EDT ---
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?
--- Additional comment from firstname.lastname@example.org on 2008-11-12 13:12:03 EDT ---
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,
--- Additional comment from email@example.com on 2008-11-13 04:38:05 EDT ---
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...
--- Additional comment from firstname.lastname@example.org on 2008-11-13 04:52:30 EDT ---
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.
--- Additional comment from email@example.com on 2008-11-13 04:54:51 EDT ---
Created an attachment (id=323427)
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
--- Additional comment from firstname.lastname@example.org on 2008-11-13 10:28:37 EDT ---
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?
--- Additional comment from email@example.com on 2008-11-13 10:52:47 EDT ---
Could this be more of Bug 450488 perhaps?
Please discuss suspend here
First: True. But I'm missing point, why you want to suspend primary terminal.
Second: No. F9 and F10 has the same behavior.
Third: I don't see any problem in bash neither in gnome-terminal. Why you want to suspend primary shell? I really don't see any sense.
Are you saying you don't understand why anyone would use suspend? Once you decide suspend is useful you obviously want to do it from a console or from a gnome-terminal.
The problem is that it is trivial to accidentally type it at the primary shell and leave yourself with a hung shell. You su to another user (say postgres to work on a database), then you suspend to test it, then you forget which shell you're in (because the prompt is identical) and suspend again, and you've got a stopped shell.
I don't want to suspend a primary shell, I want the primary shell under gnome-terminal to say "Can't suspend a login shell" just like the console does.
Yeah, no I understand you.
You can run:
gnome-terminal -e "bash -l"
and you are in login shell
With about almost 25 years of unix experience, it's faster for me to jump between shells using only the keyboard than it is to grab a mouse, find a window that may be buried, type two commands, then go back to the first shell.
I get to stay in the same shell, type fg, execute a command, and type suspend.
Are you arguing that typing suspend at a gnome-terminal shell and having it hang is the right behaviour? Particularly when the shell recognizes this as a problem and has a means of handling it in a more reasonable way?
OK. I change component to gnome-terminal and we will see... Can we run shell under gnome-terminal as login shell?
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:
Please use gconf-editor, then go to
apps => gnome-terminal => profiles => Default => login_shell
and check the case.
Does that work for you ?
For me it works :) Question is, if it works for initial reporter.
Daryll does that work for you?
Yes. That gives the "Can't suspend a login shell" message I expect. I'd argue it should be the default, but that's a personal choice, so if you disagree so be it.
We can wrap this one up.
But I've got another strange process behaviour. Start a process. Put it in the background. Then kill the shell. The subprocess dies and it shouldn't. I'll file a new bug report for that one.
Setting Severity to Low since a workaround exists.
Switching to ASSIGNED so that gnome-terminal maintainer can comment or change default behaviour if needed.
Fedora Bugzappers volunteer triage team
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. 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 '10'.
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 10'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 10 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.