Bug 470968 - Strange exit/suspend behavior
Strange exit/suspend behavior
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: upstart (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
:
: 472970 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-10 23:56 EST by Daryll
Modified: 2014-06-18 04:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-21 05:46:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace of bash running under gnome-terminal (6.56 KB, application/octet-stream)
2008-11-11 10:46 EST, Daryll
no flags Details
strace of mingetty running bash (7.72 KB, application/octet-stream)
2008-11-11 10:56 EST, Daryll
no flags Details
tty5 event (306 bytes, application/octet-stream)
2008-11-13 04:54 EST, Roman Rakus
no flags Details

  None (edit)
Description Daryll 2008-11-10 23:56:06 EST
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.
Comment 1 Roman Rakus 2008-11-11 05:34:50 EST
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?
Comment 2 Daryll 2008-11-11 10:43:17 EST
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
Comment 3 Daryll 2008-11-11 10:46:45 EST
Created attachment 323183 [details]
strace of bash running under gnome-terminal
Comment 4 Daryll 2008-11-11 10:56:08 EST
Created attachment 323186 [details]
strace of mingetty running bash
Comment 5 Roman Rakus 2008-11-12 06:38:48 EST
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?
Comment 6 Daryll 2008-11-12 13:12:03 EST
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,
Comment 7 Roman Rakus 2008-11-13 04:38:05 EST
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...
Comment 8 Roman Rakus 2008-11-13 04:52:30 EST
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.
Comment 9 Roman Rakus 2008-11-13 04:54:51 EST
Created attachment 323427 [details]
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
Comment 10 Daryll 2008-11-13 10:28:37 EST
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?
Comment 11 Casey Dahlin 2008-11-13 10:52:47 EST
Could this be more of Bug 450488 perhaps?
Comment 12 Bug Zapper 2008-11-26 00:10:22 EST
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 13 Roman Rakus 2008-11-26 06:24:27 EST
*** Bug 472970 has been marked as a duplicate of this bug. ***
Comment 14 Bernie Innocenti 2008-11-26 13:04:52 EST
I'm unable to reproduce it in the console, running F10 on x86_64.
Comment 15 Bernie Innocenti 2008-12-21 05:46:40 EST
Seems to be fixed in F10.

Please reopen if it's not the case.

Note You need to log in before you can comment on or make changes to this bug.