Lockd Congela uma ou mais vezes por dia

0

O servidor está em funcionamento há mais de 1,5 anos, sem problemas. Na semana passada começou a receber erros e congelamento de estações de trabalho: lockd: não pode monitorar statd: server rpc.statd não está respondendo, expirou

Servidor: SO: Ubuntu 10.04.4 Kernel: Linux 2.6.32-51-server nfs-common 1: 1.2.0-4ubuntu4.2 nfs-kernel-server 1: 1.2.0-4ubuntu4.2 / home x.x.x.0 / 255.255.0.0 (rw, no_root_squash, inseguro, assíncrono, wdelay, no_subtree_check) / public x.x.x.0 / 255.255.0.0 (rw, no_root_squash, inseguro, assíncrono, wdelay, no_subtree_check)

Estações de trabalho: Ubuntu 10.04.x servidor: / home / home nfs defaults 0 0 servidor: / public / mnt / public nfs defaults 0 0

Ran rpcinfo -p de estações de trabalho e de servidores retornam ok.

Enquanto congelado, o servidor é 100% acessível, ou seja, ssh top df retorna como esperado. No entanto, as estações de trabalho são incapazes de se mover entre os desktops e não respondem, o Chrome pára de funcionar

No servidor ps -aux | grep lockd mostra que o processo lockd é D. No entanto, após alguns minutos, o lockd retorna para S e R, e as estações de trabalho estão funcionais novamente

Depois de ativar o nlm_debug, vejo que, de fato, o processo lockd fica preso

Eu observo no log abaixo que o lockd fica preso por um minuto 02:03:21 - 02:04:21

Isso se repete quando o lockd fica preso e descobri isso reiniciando a estação de trabalho "ofensiva" todos os sistemas voltam a funcionar normalmente.

Oct  2 02:04:21 fs1 kernel: [647001.312596] lockd: request from 172.x.x.x, port=960
Oct  2 02:04:21 fs1 kernel: [647001.312603] lockd: LOCK          called
Oct  2 02:03:21 fs1 kernel: [646941.418685] lockd: nlmsvc_lookup_host(host='roi-lnx', vers=4, proto=tcp)
Oct  2 02:03:21 fs1 kernel: [646941.418687] lockd: get host roi-lnx
Oct  2 02:03:21 fs1 kernel: [646941.418688] lockd: nlm_lookup_host found host roi-lnx (172.16.16.76)
Oct  2 02:03:21 fs1 kernel: [646941.418689] lockd: nsm_monitor(roi-lnx)
Oct  2 02:04:21 fs1 kernel: [647001.312552] statd: server rpc.statd not responding, 
timed out
Oct  2 02:04:21 fs1 kernel: [647001.312565] lockd: NSM upcall RPC failed, status=-5
Oct  2 02:04:21 fs1 kernel: [647001.312570] lockd: cannot monitor roi-lnx
Oct  2 02:04:21 fs1 kernel: [647001.312572] lockd: release host roi-lnx

Isso parece um bug no lockd.

Eu passei dias pesquisando no Google, e há alguns casos semelhantes, mas sem correções.

Por favor, deixe-me saber se você tem alguma sugestão para resolver este problema.

Obrigado Laurence

    
por user197989 02.10.2013 / 09:06

2 respostas

1

Em um ambiente similar ao 10.04.4, o ubuntu nfs-server serve aprox. 50 ubuntu / mac os x clientes (principalmente 12.04.3), eu tive o mesmo problema. Os clientes só estavam trabalhando quando montavam os diretórios home com a opção nolock (o que não se deveria fazer).

Após a depuração de todas as coisas possíveis na rede por duas semanas, percebi depois de encontrar , que a única mudança foi incluir dois novos clientes (12.04.3) com a execução do kernel 3.8.0-29-genérico. Depois de tirar esses dois da rede (na verdade, ontem), o statd e o lockd estão estáveis novamente no servidor.

Vou relatar o que acontece hoje, quando todos os clientes estiverem em plena operação novamente.

Existe algum novo cliente na sua rede?

    
por marz_cyclone 07.10.2013 / 07:57
0

Eu também tive a experiência semelhante em um cluser de 4 nós onde todos os nós estão usando o 3.2.0-38-generic no Ubuntu 12.04.5. A versão do nfs é:

dpkg -la | grep nfs
ii  libnfsidmap2                       0.25-1ubuntu2               NFS idmapping     library
ii  nfs-common                         1:1.2.5-3ubuntu3.2                                  NFS support files common to client and server
ii  nfs-kernel-server                  1:1.2.5-3ubuntu3.2                                  support for NFS kernel server

Verifica-se que um dos nós problemáticos está constantemente "atacando o servidor NFS". Uma vez que o nó problemático é retirado do sistema, nenhum travamento ocorrerá novamente.

    
por Chenming Zhang 21.12.2014 / 14:36