Bug 84954 - strace sometimes leaves processes in "STOPPED" state
strace sometimes leaves processes in "STOPPED" state
Status: CLOSED DUPLICATE of bug 71166
Product: Red Hat Linux
Classification: Retired
Component: strace (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Roland McGrath
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-24 05:10 EST by Henning Schmiedehausen
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:51:57 EST
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 Henning Schmiedehausen 2003-02-24 05:10:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020918

Description of problem:
Tracing a live process with -p <pid> sometimes puts this process
into "STOPPED" state and doesn't resume it when strace is finished.

This seems to be a known bug in strace-4.4 (in the current release
4.4.94 there is

* Fixed bugs with attach/detach leaving things stopped.

in the NEWS file.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Open two windows on a RH 7.3 host.
2. Start a new bash in one of the windows. Get its PID with echo $$
3. Trace this new shell from the second window. In my example:

window1%  bash
window1%  echo $$
28305

window2%  strace -f -p 28305
read(0, 

Now enter ^C in window2
window2%

And in window1:
[1]+  Stopped                 bash
bash-2.05a$ 
   

Actual Results:  ===> The bash gets stopped and never restarted by the strace. 


Expected Results:  The bash should continue running after the tracer detached.



Additional info:

This is ugly for an interactive process like "bash" and deadly
for a daemon process.

I put this bug on "high" level, because "normal" admins might trace
daemon processes like sendmail or named to check for problems and
suddently the daemon process no longer runs (because it stays in
stopped state).
Comment 1 Roland McGrath 2003-02-24 16:14:36 EST

*** This bug has been marked as a duplicate of 71166 ***
Comment 2 Red Hat Bugzilla 2006-02-21 13:51:57 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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