Eu fiz o login como root, mas strace me dá isso:
root@kyznecov-System:/home/kyznecov# ps -e | grep 111 3807 pts/2 00:00:00 111 3810 pts/2 00:00:00 111 root@kyznecov-System:/home/kyznecov# strace -p 3810 attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted 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 root@kyznecov-System:/home/kyznecov root@kyznecov-System:/home/kyznecov# cat /proc/sys/kernel/yama/ptrace_scope 0
Eu então tentei usar gdb para depurar um programa multiprocessado no Eclipse CDT com bifurcação, e ele me deu o mesmo resultado / erro:
Alguma idéia?
Um motivo para receber o erro:
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
é porque o processo já foi anexado a gdb , strace ou similar. Para verificar se este é o caso, execute:
grep TracerPid /proc/$THE_PID/status
Se for diferente de zero, esse é o pid de um programa existente que já está executando um rastreamento nesse processo.
Como izx comentou, isso só deve acontecer devido a um bug do kernel. Assim, qualquer pessoa que possa atualmente produzir este problema - incluindo e especialmente o cartaz original desta questão - seria bem aconselhada a relate-o como um bug lendo a página completa e cuidadosamente e, em seguida, executando ubuntu-bug linux na máquina afetada . Isso deve ser reportado contra linux no Ubuntu, e não em um kernel principal (upstream), a menos que você possa produzi-lo em um kernel mainline (você teria que ter yama carregado).
O comportamento esperado em todas as versões do Ubuntu a partir do Ubuntu 10.10 é que o processo A não pode rastrear um processo em execução B, a menos que B seja um filho direto de A (ou A seja executado como root ). Esse é um aprimoramento de segurança, o que faz com que um processo que tenha sido comprometido por um invasor não possa usar os recursos de depuração fornecidos pelo kernel para descobrir informações de outros processos. Isso é explicado na seção ptrace scope da página wiki da comunidade Security Features .
Esse comportamento restritivo é o padrão, mas pode ser alterado para permitir que um processo A rastreie qualquer processo em execução B que seja executado com o mesmo ID de usuário do processo A. Ou seja, você pode configurar seu sistema para permitir que qualquer um dos seus processos depure um ao outro. Isso simplifica a conexão de depuradores a processos já em execução.
A configuração para isso é exposta pelo /proc/sys/kernel/yama/ptrace_scope sysctl . 1 denota o comportamento mais restritivo e 0 o comportamento menos restritivo. A configuração pode ser lida com:
cat /proc/sys/kernel/yama/ptrace_scope
O comportamento menos restritivo (não padrão) pode ser definido com:
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
E o comportamento mais restritivo (padrão) pode ser definido (ou retrocedido) com:
echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope
O postador original dessa pergunta não só não conseguiu anexar uma instância strace a um processo em execução no momento com ptrace-scope definido como 0 , mas o postador original ainda não conseguiu fazê-lo ao executar strace como root . É difícil ver como isso pode ser qualquer coisa além de um bug - recomendo enfaticamente denunciá-lo como um.
No início, eu pensava que era possível reproduzir o problema em que uma configuração ptrace_scope de 0 é ignorada e tratada como se fosse 1 . Mas não acredito mais que seja esse o caso, já que fiz as mesmas coisas novamente e não consigo reproduzir o problema. Eu testei isso em:
Em todas as três máquinas, o comportamento esperado ocorre e não consigo reproduzir a condição sobre a qual o pôster original dessa pergunta está perguntando. Aqui está um texto do Terminal (do sistema ao vivo preciso):
lubuntu@lubuntu:~$ nano&
[1] 3492
lubuntu@lubuntu:~$ strace -p 3492
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
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
[1]+ Stopped nano
lubuntu@lubuntu:~$ cat /proc/sys/kernel/yama/ptrace_scope
1
lubuntu@lubuntu:~$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
0
lubuntu@lubuntu:~$ strace -p 3492
Process 3492 attached - interrupt to quit
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
strace continuou produzindo mensagens até que eu as suspendesse, como esperado.
Concluo recomendando novamente denunciar isso como um bug. Uma pesquisa no máximo possível no link (que inclui quaisquer erros relatados do Ubuntu) para o texto ptrace_scope produz apenas um punhado de resultados, nos quais claramente nenhum é reportado para este bug . Relatar o bug ajudaria outras pessoas, pode levar a soluções alternativas ou a uma correção, e é provavelmente a única maneira significativa de avançar no trabalho nesse problema (supondo que o problema ainda esteja ocorrendo).
Tags kernel debugging 12.04 programming 11.10