Bug 133443
| Summary: | ^Z won't get you a command-line prompt back | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
| Component: | bash | Assignee: | 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: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 123268 | ||
I think this is fixed in bash-3.0-15; at least, I can't reproduce it with that package. Seems to have been fixed, indeed. |
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: