Bug 133443

Summary: ^Z won't get you a command-line prompt back
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: bashAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: bash-3.0-15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-02 19:44:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 123268    

Description Alexandre Oliva 2004-09-24 00:21:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
If you start a long-running process in foreground (say, let fetchmail
run overnight, or run prelink and go away from the keyboard for some
time but return before it's done), and then try to stop the process to
get a shell back, the foreground processes apparently always stop, but
sometimes bash won't get you a shell back.  Instead, it will just sit
there waiting for the process to complete, or for its state to change.
 To wit, I started:

[root@free ~]# /etc/cron.daily/prelink

and let it run for a while.  When I came back, I tried ^Z

Nothing happened.

Opening another virtual terminal in gnome-terminal, I verified that
both the shell script and the prelink binary were in T state.  bash
was obviously not.  So I ran kill -CONT to get prelink running again.
 Then I straced bash, and bang, nothing happened again, but strace showed:

waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTSTP}], WUNTRACED) =
31027
waitpid(-1,  <unfinished ...>

and that was all.  I don't think bash should have done another
waitpid.  31027 was indeed the prelink script PID, indeed.

The fact that I've only observed this in processes that I left running
overnight in the past few days (glibc updates almost daily), or in
this case of running prelink in foreground, makes me wonder if this is
related with bug 128524.  It doesn't appear directly related with
133318, but excess calls to waitpid() seem to be a common factor.  I
didn't start any processes in background, though.

Version-Release number of selected component (if applicable):
bash-3.0-14 kernel-2.6.8-1.541

How reproducible:
Sometimes

Steps to Reproduce:
1.Start say prelink
2.Walk away from the keyboard for some time
3.Get back before it completes, and try to put it in background with ^Z

Actual Results:  You can't.  ^Z stops the process, but bash won't give
you a command-line.

Expected Results:  It should.

Additional info:

Comment 1 Tim Waugh 2004-09-27 12:13:50 UTC
I think this is fixed in bash-3.0-15; at least, I can't reproduce it
with that package.

Comment 2 Alexandre Oliva 2004-10-02 19:44:48 UTC
Seems to have been fixed, indeed.