Processos estranhos no servidor consomem CPU

Question

Eu notei 15% de carga da CPU no servidor que está atualmente off-line. Ele montou o volume do GlusterFS sobre o TCP. Olhando para o topo, ele me mostrou que é glusterfs. Depois disso, tentei descobrir o que exatamente está usando e consegui:

# lsof /storage/
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF                NODE NAME
find    16433 nobody  cwd    DIR   0,19     8192 9259265867489333824 /storage/200000/200000/200700/200704/08

Então:

# ps uax | grep find
root     16415  0.0  0.0   4400   724 ?        SN   06:34   0:00 /bin/sh /usr/bin/updatedb.findutils
root     16423  0.0  0.0   4400   336 ?        SN   06:34   0:00 /bin/sh /usr/bin/updatedb.findutils
nobody   16431  0.0  0.0  39524  1376 ?        SN   06:34   0:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race      \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0
nobody   16432  0.0  0.0   4400   616 ?        SN   06:34   0:00 sh -c /usr/bin/find / -ignore_readdir_race      \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0
nobody   16433  0.3  0.0  13612  1532 ?        SN   06:34   0:38 /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex \(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\) ) -prune -o -print0

Eu matei 16432 e 16433 e a CPU agora está com% 0 novamente.

Alguém pode me dizer alguma coisa sobre esses feios comandos de busca? É possível que seja causado pelo outro servidor que também tem este / armazenamento montado?

De acordo com o monitoramento, acontece todos os dias ao mesmo tempo.

    

Answer 1

Parece que faz parte do trabalho diário updatedb que é executado para atualizar os bancos de dados usados pelo localize o comando .

Você provavelmente encontrará em /etc/cron.daily como mlocate ou similar.

Se você usa ps -ef , obtém o PID (processo) e o PPID (pai PID) que podem ser usados para rastrear. Você provavelmente teria visto que os processos que você matou tinham PPIDs 16415, 16423.

Ferramentas como pstree também são úteis para esse tipo de coisa.

pstree -p -H5295

dá saída assim

  |-sshd(5291)---sshd(5294)---bash(5295)-+-more(6098)
  |                                      '-pstree(6097)

    

Answer 2

Como Iain observou, é quase certamente updatedb(8) . O updatedb tenta realmente apenas indexar seus sistemas de arquivos locais. Na minha máquina, ele é feito apenas por incluindo sistemas de arquivos do tipo HFS e UFS. Em sua máquina, ele é feito especificamente excluindo vários tipos de sistema de arquivos, como NFS, AFS, SMB e similares.

O problema com a abordagem de exclusão, como você percebeu, é que quando alguém cria um novo tipo de sistema de rede - como GlusterFS por exemplo - updatedb precisa ser modificado para excluir também esse tipo de sistema de arquivos. p>

Para mim, updatedb é um script de shell, então posso alterar trivialmente os tipos de sistema de arquivos. Eu suspeito que isso seja verdade em seu sistema também. Supondo que o GlusterFS seja do tipo glusterfs , provavelmente você pode adicionar outro teste:

-fstype glusterfs

nessa linha de testes para outros tipos de sistema de arquivos e esteja sempre em seu caminho.

Ou, é claro, você pode simplesmente desativar updatedb se nunca usar o comando locate(1) .