Bug 133443 - ^Z won't get you a command-line prompt back
^Z won't get you a command-line prompt back
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-09-23 20:21 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: bash-3.0-15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-02 15:44:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-09-23 20:21:47 EDT
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 08:13:50 EDT
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 15:44:48 EDT
Seems to have been fixed, indeed.

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