Bug 471571

Summary: Strange suspend behavior
Product: [Fedora] Fedora Reporter: Roman Rakus <rrakus>
Component: gnome-terminalAssignee: Behdad Esfahbod <behdad>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 10CC: behdad, daryll, fdc, rrakus, tsmetana, twaugh
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 06:50:42 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:

Description Roman Rakus 2008-11-14 11:43:37 UTC
+++ 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
bash-3.2-29.fc10.i386

How reproducible:
Every time


Steps to Reproduce:
See above
  
Actual results:
Case 1: The console terminal hangs
Case 2: The gnome terminal hangs

Expected results:
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 rrakus 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 daryll 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. 
ncurses-5.6-20.20080927.fc10.i386
glibc-2.8.90-16.i686
Linux ninja 2.6.27.4-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 daryll on 2008-11-11 10:46:45 EDT ---

Created an attachment (id=323183)
strace of bash running under mingetty

--- Additional comment from daryll on 2008-11-11 10:56:08 EDT ---

Created an attachment (id=323186)
strace of mingetty running bash

--- Additional comment from rrakus 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 daryll 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 rrakus 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 rrakus 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 rrakus on 2008-11-13 04:54:51 EDT ---

Created an attachment (id=323427)
tty5 event

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 daryll 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 cdahlin on 2008-11-13 10:52:47 EDT ---

Could this be more of Bug 450488 perhaps?

Comment 1 Roman Rakus 2008-11-14 11:44:09 UTC
Please discuss suspend here

Comment 2 Roman Rakus 2008-11-14 11:56:06 UTC
Response:
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.

Comment 3 Daryll 2008-11-14 15:40:13 UTC
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.

Comment 4 Roman Rakus 2008-11-14 16:02:37 UTC
Yeah, no I understand you.
You can run:
gnome-terminal -e "bash -l"
and you are in login shell

Comment 5 Daryll 2008-11-14 16:18:26 UTC
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?

Comment 6 Roman Rakus 2008-11-21 11:01:54 UTC
OK. I change component to gnome-terminal and we will see... Can we run shell under gnome-terminal as login shell?

Comment 7 Bug Zapper 2008-11-26 05:22:11 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 François Cami 2009-02-06 00:01:27 UTC
Roman,
Please use gconf-editor, then go to
apps => gnome-terminal => profiles => Default => login_shell
and check the case.
Does that work for you ?

Comment 9 Roman Rakus 2009-02-12 15:23:14 UTC
For me it works :) Question is, if it works for initial reporter.
Daryll does that work for you?

Comment 10 Daryll 2009-02-16 07:10:05 UTC
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.

Comment 11 François Cami 2009-02-16 09:36:48 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 12 Bug Zapper 2009-11-18 09:22:33 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Bug Zapper 2009-12-18 06:50:42 UTC
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.