after upgrade gdb won't attach to process

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Pit0r]

Thanks. I added the temporary to a command in my user bin file so that I can turn it on and off works great.

[soroosh]

I edit /etc/sysctl.d/10-ptrace.conf file. it works perfectly for me. :)

[frankster]

If you have made some edits to files in /etc/sysctl.d, then you can apply them automatically with "sudo service procps restart"

[Andy Thomas]

@alexmurray - Your helpful answer should also note that a restart of some kind is necessary for the changes to /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.)

[Mircea Vutcovici]

No reboot is needed. Just run: 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

[Iluvathar]

You didn't attach, you started it. It's quite different, since in this case 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 $!"

[mpb]

Ruslan's proposed (counter?) example, 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.