O que está lançando todos esses processos rpc.statd?

4

Em nossos servidores - executando o CentOS 6 x86_64 - estamos vendo muita atividade incomum com rpc.statd . Temos rpc.statd configurado para ser executado em uma porta estática via /etc/sysconfig/nfs :

MOUNTD_PORT=892
STATD_PORT=662
QUOTAD_PORT=875

E isso resulta em rpc.statd executando e ouvindo nesta porta conforme o esperado:

# ps -fe | grep rpc.statd | grep 662
rpcuser  23129     1  0 Apr30 ?        00:00:00 rpc.statd -p 662

O que é estranho é que, nesse sistema, há também muitas outras instâncias de rpc.statd em execução com o sinalizador --no-notify :

rpcuser    808     1  0 02:23 ?        00:00:00 rpc.statd --no-notify
rpcuser   2052     1  0 07:17 ?        00:00:00 rpc.statd --no-notify
rpcuser   3558     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   5787     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   6499     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   8834     1  0 03:21 ?        00:00:00 rpc.statd --no-notify
rpcuser   9661     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  13702     1  0 00:08 ?        00:00:00 rpc.statd --no-notify
rpcuser  14813     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  15375     1  0 08:39 ?        00:00:00 rpc.statd --no-notify
rpcuser  15376     1  0 04:26 ?        00:00:00 rpc.statd --no-notify
rpcuser  19782     1  0 09:36 ?        00:00:00 rpc.statd --no-notify
rpcuser  20491     1  0 05:36 ?        00:00:00 rpc.statd --no-notify
rpcuser  23136     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  23320     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  26145     1  0 10:10 ?        00:00:00 rpc.statd --no-notify
rpcuser  26480     1  0 06:24 ?        00:00:00 rpc.statd --no-notify
rpcuser  26598     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  26821     1  0 01:15 ?        00:00:00 rpc.statd --no-notify
rpcuser  28255     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify

Também é estranho que um desses processos aparentemente tenha usurpado processo rpc.statd original, no que diz respeito ao rpcbind. Corrida rpcinfo relatórios statd nas seguintes portas:

# rpcinfo -p
...
100024    1   udp  34322  status
100024    1   tcp  41686  status

Correspondem ao PID 26145 (que você pode ver como um dos rpc.statd instâncias na saída acima de ps ).

Isso não seria um problema se tudo estivesse funcionando, mas ontem sistema começou a experimentar um problema com montagens NFS ... qualquer tentativa de montar um novo sistema de arquivos resultaria em:

mount.nfs: mount system call failed

Eliminar todos os serviços rpc.statd "resolveu" o problema, mas estamos intrigados com o que está acontecendo aqui. Nós nunca vimos isso comportamento em nossos sistemas CentOS 5 da mesma forma configurados.

    
por larsks 01.05.2012 / 16:44

1 resposta

2

Bem, isso parece ser parcialmente culpa nossa e parcialmente um erro no comando authconfig do RedHat. Nossa configuração do Puppet estava causando authconfig --updateall a ser executado a cada hora. Isso era desnecessário, mas geralmente não deveria ser um problema ... exceto que authconfig reinicia o serviço rpcbind .

Reiniciar rpcbind faz com que esqueça todos os serviços que se registraram nele. Embora o authconfig reinicie os serviços relacionados ao NIS, isso resulta em uma situação em que rpc.statd ainda está em execução, mas não mais registrado com rpcbind - o que torna efetivamente invisível do ponto de vista dos aplicativos que tentam encontrar via rpcbind .

Eu consertei a configuração do Puppet para que ele não chame mais o authconfig , e eu abri o bug 818246 com RedHat.

    
por 02.05.2012 / 16:56