Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this community
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?
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.
/etc/sysctl.d/10-ptrace.conf file. it works perfectly for me. :)
/etc/sysctl.d to become effective. For me, a system restart was sufficient, but may have been overkill -- see frankster's comment above. After the restart, the value from /etc/sysctl.d is copied into /proc/sys/kernel/yama/ptrace_scope. (Also, in my case I could not edit ptrace_scope directly, even with sudo.)
Mar 26, 2015 at 21:04
sysctl -p to apply changes from /etc/sysctl.conf and /etc/sysctl.d/*. For this specific change, in Ubuntu 15.04 Vivid , the file is /etc/sysctl.d/10-ptrace.conf
Aug 11, 2015 at 14:52
If you prefer to leave /proc/sys/kernel/yama/ptrace_scope set to its default value of 1, then as a workaround you could consider using gdb to run the program you want to debug. You can then bring up the debugger simply by pressing ^C. For example, to debug 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
^C
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
Continuing.
[Inferior 1 (process 3531) exited normally]
(gdb) quit
Since /bin/sleep was (unsurprisingly) compiled without debugging information, the above backtrace contains minimal information.
gdb is direct parent of the debuggee and has every right to debug it even with ptrace_scope==1. It wouldn't work if you instead attached, i.e. did something like sleep 60& gdb -ex "attach $!"
sleep 60& gdb -ex "attach $!" is not "using gdb to run the program", and therefore is not a refutation of my workraound. Ruslan's example is using the shell to first run sleep and then run gdb. My workaround works, which is what I care about. I do not know, nor do I really care, whether or not gdb is actually attaching to its child. I care about being able to debug the child. My workaround accomplishes that. Nonetheless, I have reworded my answer for clarity.