Desperate: statd expirou, o lockd não pode monitorar / unmonitor

1

Desde esta tarde, algo está errado com o servidor. No lado do servidor, vejo mensagens em dmesg da seguinte forma:

statd: server rpc.statd not responding, timed out
lockd: cannot unmonitor <client>
statd: server rpc.statd not responding, timed out
lockd: cannot monitor <client>

No lado do cliente, vejo em dmesg :

lockd: server <server> not responding, still trying
lockd: server <server> OK

Isso está paralisando toda a rede! Eu tentei esta solução sugerido por Xian, mas não faz diferença.

Servidor, Debian Linux, Squeeze 64-bit:

>> uname -a
Linux <server> 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

Clientes, Linux Mint 13-64bit:

>> uname -a
Linux <client> 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Eu não executei uma atualização no servidor, então não sei o que poderia ter mudado. Eu atualizei uma de nossas máquinas clientes, mas não vejo por que isso iria mexer com o servidor, já que todas as máquinas parecem afetadas. Alguma idéia de como consertar isso?

UPDATE 1

O servidor parou por um tempo em

Starting portmap deamon
Starting NFS common utilities: statd idmapd

Isso leva cerca de 2 minutos até que a inicialização continue ...

UPDATE 2

É de fato a máquina cliente que foi atualizada que causou isso. Parece que de alguma forma parou statd no servidor, fazendo com que todas as outras máquinas tenham problemas. Eu reiniciei toda a rede, deixando essa máquina desligada e não encontrei nenhum problema. Não é realmente uma correção, mas eu já fiz o downgrade dessa máquina novamente, e tudo parece estar estável.

    
por Markus 31.07.2013 / 01:55

4 respostas

1

Aqui vem algumas sugestões:

Uma vez eu consegui quebrar a interface de loopback ( lo ) e graças a ela vários serviços, como o NFS, pararam de funcionar corretamente. Veja com ifconfig se você ainda tem sua amada lo interface em funcionamento. Se não for, vá ver /etc/network/interfaces e veja o que está acontecendo.

Além disso, como algumas pessoas já mencionadas, verifique os comandos pgrep -v statd e netstat -tlnpu para ver se o statd está sendo executado.

Ou talvez alguém tenha alterado alguma coisa abaixo de /etc no lado do servidor? Se você não tiver /etc sob controle de versão, veja se algum arquivo foi modificado recentemente: find /etc -mtime -14 mostrará arquivos alterados durante os últimos 14 dias, por exemplo.

    
por 31.07.2013 / 06:56
1

Dê uma olhada aqui: link

Tente:

# /etc/init.d/nfs-common stop
# /etc/init.d/nfs-kernel-server stop
# rm -rf /var/lib/nfs/statd/sm/*
# rm -rf /var/lib/nfs/statd/sm.bak/*
# /etc/init.d/nfs-common start
# /etc/init.d/nfs-kernel-server start

Eu tive o mesmo problema, e isso resolveu ... mas por apenas um mês. Eu não sei porque agora. Eu tive que deletar os arquivos novamente hoje.

    
por 15.11.2013 / 15:06
0

Eu tive o mesmo problema em um servidor nfs debian squeeze, e pareceu ser desencadeado por alguns novos clientes também (Fedora 20). Fazer o downgrade dos clientes não era uma opção para mim, depois de algum longo, doloroso e malsucedido debugging acabei descobrindo um bug de loop readdir (diferente e provavelmente não relacionado) no sistema de arquivos ext4 exportado do nfs com muitos arquivos semelhantes a: link

(Eu posso estar errado, do pouco eu entendi que isso foi corrigido nos kernels recentes, então squeeze debian pode ser afetado)

longa história curta, para se livrar pelo menos desse bug eu atualizei meu servidor nfs para debian wheezy (forçando a versão nfs para 3) e agora (com o mesmo sistema de arquivos e os mesmos clientes) tem sido uma semana sem o " não pode monitorar "/" não respondendo "problema (antes da atualização era uma coisa diária)

    
por 10.07.2014 / 14:15
0

Isso funcionou no meu caso:

link

Just edit the /etc/init.d/halt script, at the end there should be the line

halt -d -f -i $poweroff $hddown

The "-i" option makes all network interfaces to be shutdown, but this >seems to be too early for diskless clients, just try to remove this option, so

halt -d -f $poweroff $hddown

Note que o meu problema foi com o NFS no cliente com disco.

    
por 26.07.2016 / 10:21