Bug 71166

Summary: strace -p pid suspends pid when strace exits
Product: [Retired] Red Hat Public Beta Reporter: Jay Berkenbilt <ejb>
Component: straceAssignee: Jakub Jelinek <jakub>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: limboCC: bbaetz, ejb, hps, jwm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-08-10 20:38:37 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: 67218    

Description Jay Berkenbilt 2002-08-09 15:04:42 UTC
Description of Problem:

When you run strace -p on a process and then interrupt strace, the traced
process ends up suspended after strace exits.  This is somewhat similar to the
problem reported in bug 63370, but much simpler and slightly different, so I've
decided to open a new bug rather than have that complex one kicking around for a
tiny aspect of the original problem.  This problem exists in Limbo and also in
Valhalla.

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

strace-4.4-4, kernel 2.4.18-3, -5 (Valhalla)
strace-4.4-6, kernel 2.4.18-7.80 (Limbo)


How Reproducible:

always


Steps to Reproduce:
1. /bin/sleep 10 &
2. strace -p $!
3. CTRL-C

Actual Results:

strace exits, the sleep process suspends

Expected Results:

the traced process should not be left suspended

Additional Information:

This does not depend upon the fact that the sleep process is in system call when
strace exits.  You can do the same experiment with the following C program:

int main() { while (1) {} }

which clearly doesn't call any system calls once it starts.  If you start this
in the background and then strace it and exit strace, it too stops.  It also
doesn't have anything to do with controlling ttys or job control -- you can
start this is (./a.out < /dev/null > /dev/null 2>&1 &) and then strace -p its
pid from another shell.  The same thing happens.

This is most disconcerting when done on a system process.  Unlike in some
previous situations, kill -CONT does restore everything to normal, but one
doesn't expect strace to leave things in a suspended state.  I'm marking this as
severity "high" because there is no known workaround.  I don't have any idea 
what the fix is, though I suppose it may work to have the strace process
explicitly send a CONT signal to the process after releasing it.  This would, of
course, just be a workaround and not a correct fix....   I don't know whether
this is an strace issue or a kernel issue.  I haven't experimented with 
multithreaded programs with respect to this problem.

Comment 1 Roland McGrath 2002-08-20 23:06:27 UTC

*** This bug has been marked as a duplicate of 64303 ***

Comment 2 Roland McGrath 2003-02-24 21:14:39 UTC
*** Bug 84954 has been marked as a duplicate of this bug. ***