Bug 86382 - if use strace on kernel-2.4.18-27.7.x, must use SIGCONT to awaken traced process
Summary: if use strace on kernel-2.4.18-27.7.x, must use SIGCONT to awaken traced process
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-20 23:02 UTC by Martin A. Brown
Modified: 2007-04-18 16:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-07 19:39:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Martin A. Brown 2003-03-20 23:02:56 UTC
Description of problem:

Strace, under kernel 2.4.18-27.7.x (with the ptrace fix) appears to fail
immediately, citing lack of privilege, and put the process into a STOPped state.
 (SIGSTOP).

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

I see the same behaviour under redhat 7.2 and redhat 7.3 boxen.

How reproducible:

Probably many ways...but I was able to choose a non-root running process which
was attached to a port <1024.  This means the process had to have been root and
dropped privileges.

Steps to Reproduce:
1. See actual results where I have snipped a session.
2.
3.
    
Actual results:

# pidof  lpd
1050
# strace -f -p 1050
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
# ps wwwwwu 1050
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
lp        1050  0.0  0.2  2564  696 ?        T    Mar18   0:00 [lpd]
# kill -CONT 1050
# ps wwwwwu 1050
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
lp        1050  0.0  0.2  2564  696 ?        S    Mar18   0:00 [lpd]


Expected results:

I expect strace, when run by root, to be able to attach to any child process. 
(No kernel capabilities or anything strange getting in our way here....)

Additional info:

I tried building a newer strace (rpm -ta ./tmp/strace-4.4.94.tar.bz2) from
http://sourceforge.net/projects/strace/, but this strace, too exhibited the same
behaviour.

Thankfully, sending the process a SIGCONT clears up the apparent hang of the
daemon, but this is distinctly not expected behaviour.

Thank you very much for your attention in this matter,

-Martin

Comment 1 Rafi Khardalian 2003-03-31 04:10:01 UTC
Noticed identical behavior on all our systems running 2.4.18-27. It's rather 
hindering and I'm surprised more people haven't reported it (though I'm just 
as guilty). An answer/solution would be greatly appreciated. 

Thanks.

- Rafi


Comment 2 Hannu Kivimäki 2003-04-07 10:44:49 UTC
I have the same problem with strace on Red Hat 8.0,
kernel 2.4.18-27.8.0smp, strace 4.4.95-2 from Raw Hide.

I'm trying to debug a cgi program by tracing Apache,
but strace fails with "Operation not permitted".

 [root@linux root]# httpd -X &
 [1] 12522
 [root@linux root]# strace -p 12522
 trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
 detach: ptrace(PTRACE_DETACH, ...): Operation not permitted

Note that I tried gdb as well (following instructions from Apache
Debugging Guide), but didn't get any further:

 (gdb) where
 Couldn't get registers: Operation not permitted.

Perhaps this problem is not related to strace at all?


Comment 3 Arjan van de Ven 2003-06-07 19:39:25 UTC
fixed in current erratum


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