Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I just recently upgraded from 10.04 to 11.04 and gdb won't allow me to attach to processes anymore I get the error

Attaching to process 10144 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted.

How do I fix this so that I can debug again without sudo?

share|improve this question

2 Answers 2

up vote 39 down vote accepted

In Maverick Meerkat (10.10) Ubuntu introduced a patch to disallow ptracing of non-child processes by non-root users - ie. only a process which is a parent of another process can ptrace it for normal users - whilst root can still ptrace every process. Hence why you can use gdb to attach via sudo still.

You can temporarily disable this restriction (and revert to the old behaviour allowing your user to ptrace (gdb) any of their other processes) by doing:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

To permanently allow it edit /etc/sysctl.d/10-ptrace.conf and change the line:

kernel.yama.ptrace_scope = 1

To read

kernel.yama.ptrace_scope = 0

For some background on why this change was made, see the Ubuntu wiki

share|improve this answer
Thanks. I added the temporary to a command in my user bin file so that I can turn it on and off works great. –  Andrew Redd May 10 '11 at 15:08
I edit /etc/sysctl.d/10-ptrace.conf file. it works perfectly for me. :) –  soroosh Apr 20 '13 at 14:29
If you have made some edits to files in /etc/sysctl.d, then you can apply them automatically with "sudo service procps restart" –  frankster Jul 18 '13 at 14:33

If you can use gdb to run the program you want to attach to, then you can "attach" to it by pressing ^C. For example, to attach to the (boring) program sleep 60, do the following:

$ gdb -q sleep -ex 'run 60'

Here is a complete example.

$ gdb -q sleep -ex 'run 60'
Reading symbols from sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
Program received signal SIGINT, Interrupt.
0x00007ffff7ad5d60 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) backtrace
#0  0x00007ffff7ad5d60 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x0000000000403cd7 in ?? ()
#2  0x0000000000403b88 in ?? ()
#3  0x00000000004016c9 in ?? ()
#4  0x00007ffff7a35ec5 in __libc_start_main (main=0x401540, argc=2, argv=0x7fffffffea08, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe9f8) at libc-start.c:287
#5  0x00000000004017d5 in ?? ()
(gdb) continue
[Inferior 1 (process 3531) exited normally]
(gdb) quit

Since /bin/sleep was (unsurprisingly) compiled without debugging information, the above backtrace contains minimal information.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.