Bug 133443 - ^Z won't get you a command-line prompt back
Summary: ^Z won't get you a command-line prompt back
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-09-24 00:21 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: bash-3.0-15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-02 19:44:48 UTC

Attachments (Terms of Use)

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)

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) =
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:

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.

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