Monitora processos tentando acessar arquivos ou diretórios inexistentes

3

Estamos movendo os sites de uma configuração de servidor para uma nova configuração e os sites viverão em caminhos diferentes dos anteriores. Estamos planejando percorrer e substituir caminhos antigos com novos caminhos, mas no caso de perdermos algum, existe alguma maneira de monitorar qualquer processo que tente acessar os caminhos antigos e também saber de que UID o processo pertence? / p>     

por sa289 24.07.2015 / 06:11

3 respostas

5

Você pode usar este pequeno script systemtap:

#!/usr/bin/stap
function proc:string() { return sprintf("PID(%d) UID(%d) PROC(%s)", pid(), uid(), execname()) }

probe syscall.open.return, syscall.stat.return,
  syscall.open64.return ?, syscall.stat64.return ? {
  filename = user_string($filename)
  if ($return < 0) {
    printf("failed %s on %s by %s\n", pn(), proc(), filename)
  }
}

Ele conectará os syscalls abertos e stat (você pode copiar / colar o código, talvez eu tenha esquecido outros syscalls) no retorno. Como syscalls são a única maneira de se comunicar com o kernel, você não perderá nada. Este script produzirá esse tipo de saída:

failed syscall.stat.return on PID(4203) UID(1000) PROC(bash) by /tmp/rofl
failed syscall.stat.return on PID(4203) UID(1000) PROC(bash) by /tmp/hihi

entre os profissionais de usar o systemtap, temos:

  • menos instrusivo para o processo
  • em todo o sistema (não apenas o processo monitorado), mas você pode reduzir sua seleção diretamente no script
  • menos ressource faminto (somente exibe ações com falha, nem todas para serem grep depois)
  • você pode melhorar o script para obter os detalhes sobre o programa de chamada (por exemplo, seu backtrace, tempo de chamada, etc ...). Depende da sua aplicação.

E para os contras:

  • não padrão, você precisa instalá-lo (mas padrão o suficiente para estar disponível na maioria das distribuições). No Redhat & variantes: sudo yum install systemtap
  • precisa ter o debuginfos para construir o módulo. No Redhat & variantes: sudo debuginfo-install kernel

Alguns links úteis: O índice do tapset (funções incluídas) e um guia para iniciantes

Boa sorte para sua migração!

    
por 28.07.2015 / 10:03
1

Algo como isso deve acontecer:

strace -f \
-e trace=open,stat,stat64,lstat,lstat64,chdir,mkdir,rename,symlink,creat \
 -o >(grep "the paths you want to catch" > log) \
commandToStartYourServer

Você deseja que a opção -f rastreie os processos filhos. As opções de rastreio são um subconjunto do que fabricate usa para rastrear IO (fabricar rastreios "open,stat,stat64,lstat,lstat64,execve,exit_group,chdir,mkdir,rename,clone,vfork,fork,symlink,creat" )

Isso limita ainda mais o disco IO, filtrando a saída via grep e processo de substituição (basicamente um pipe no nível do sistema).

    
por 28.07.2015 / 02:07
1

Você poderia usar o fatrace. O suporte ao kernel (fanotify) deve estar presente na maioria dos sistemas modernos, mas o aplicativo fatrace userspace não está nos repositórios padrão para alguns SOs. O fatrace é particularmente interessante se seus arquivos antigos estiverem em um sistema de arquivos separado.

link

-

Muito mais comum, embora um pouco mais difícil de usar, é auditado.

link

-

Existe um problema fundamental no monitoramento do uso de arquivos por caminho quando os links simbólicos permitem o acesso por meio de caminhos completamente diferentes, portanto, é necessário prestar atenção especial a isso.

    
por 31.07.2015 / 15:45