reinicia o cliente NFS sem reiniciar

Question

Eu tenho trabalhado no meu servidor, do qual eu exporto um diretório usando o NFS. É claro que ao longo da semana de reinicializações do servidor, várias vezes esqueci de umount do sistema de arquivos de exportação em minha estação de trabalho (que é montado a partir de /etc/fstab na inicialização). Entre eu pude umount após o fato e remontar (eu sou não usando autofs ):

umount -fl /data0
mount /data0

Mas isso não funciona mais.

I não é possível montar o diretório exportado do servidor em um diretório diferente (a montagem é interrompida), mas posso nfs montar esse diretório exportado em uma máquina virtual em execução no meu posto de trabalho.

O que tentei é remover ( rmmod ) o módulo nfs e nfsv3 (o que não funcionaria: Resource temporarily unavailable ). lsof trava. mount não mostra nada montado via nfs . Isso tudo é provavelmente o resultado de usar 'umount -l' várias vezes, mas as duas primeiras vezes isso funcionou sem problemas.

Eu reiniciei o servidor nesse meio tempo, depois de não poder montar sem fazer qualquer diferença. Eu também usei service nfs-kernel-server restart . Eu suspeito que tudo voltaria ao normal se eu reiniciar a estação de trabalho do cliente.

Existe uma maneira de recuperar isso e reinicializar o lado do cliente nfs em minha estação de trabalho sem reiniciar?
Se eu não puder consertar isso sem reiniciar, isso não ocorreria novamente se eu começar a usar autofs ?

lsof -b trava com as últimas linhas:

lsof: avoiding readlink(/run/user/1001/gvfs): -b was specified.
lsof: avoiding stat(/run/user/1001/gvfs): -b was specified.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/gvfs
      Output information may be incomplete.

nas linhas anteriores, não há /data0 .

A entrada em /etc/fstab :

192.168.0.2:/data0 /data0  nfs  defaults,auto,nolock,user 0 2

    

Answer 1

Como @PaperMonkey sugerido nos comentários, você pode estar ferrando porque usou as opções de montagem padrão, que incluem novas tentativas para sempre.

intr costumava ser uma forma de facilitar a interrupção de itens que estavam presos na E / S para uma montagem NFS quebrada, mas agora é um não operacional. SIGKILL ainda pode interromper processos presos no NFS, pelo menos, nfs(5) de declarações. Veja essa página man para opções de montagem.

Use soft em vez do padrão hard se você quiser que o NFS não tente novamente para sempre.

Eu também recomendo usar o montador automático. Faça links simbólicos para / net / host / foo / bar em algum lugar, se quiser.

Geralmente, é mais fácil reinicializar, mas acho que, em teoria, você deve ser capaz de kill -9 (ou seja, kill -KILL ) de quaisquer processos que estejam presos no NFS. Então, umount -f pode funcionar. Apenas tome cuidado para não permitir que a conclusão de tabulação coloque mais processos na montagem NFS.

    

Answer 2

Abaixo está uma lista de comandos a serem executados para corrigir este problema em uma distribuição baseada em RPM.

service rpcbind stop
service nfslock stop
rm -rf /var/lib/nfs/statd/sm/*
rm -rf /var/lib/nfs/statd/sm.bak/*

Depois disso:

umount -f /share

    

Answer 3

Usar autofs ajudará a evitar esse problema no futuro. O maior benefício para autofs é que ele não tenta montar o diretório até que você tente usá-lo, isso significa que você evita pontos de montagem quebrados e que ele não tentará montar indefinidamente, você pode definir um período de tempo limite para desmontar ( que normalmente é curto). Não tenho certeza se o automount tenta novamente durante esse período, mas de qualquer forma eu normalmente configuro o tempo limite do automount em apenas alguns segundos.

Para resolver o problema sem reiniciar você pode conseguir com umount -a (desmontar todos os mencionados em / etc / fstab) mount -a (montar todos em / etc / fstab) mas Eu tenho a menos que o diretório que você perdeu contém o diretório home que você é melhor para salvar o trabalho em outro lugar e apenas reinicializar.

    

Answer 4

Use os resultados do comando lsof para localizar os processos no cliente que contêm referências ao sistema de arquivos obsoletos e eliminar esses processos.

umount -f / data0

garanta que você pode executar ping no servidor e remontar a unidade. Reinicie todos os processos desejados.

Clusters

Observe que, se você executar uma configuração de servidor de cluster, obterá um identificador de arquivo nfs obsoleto toda vez que o servidor precisar efetuar o failover. Para evitar isso, você deve exportar seus sistemas de arquivos usando a opção fsid. O número para o fsid deve ser o mesmo para cada sistema de arquivos respectivo nos dois servidores. Cabe a você garantir a replicação dos arquivos. Veja o snippet da página man abaixo:

fsid = num | raiz | uuid O NFS precisa ser capaz de identificar cada sistema de arquivos que exporta. Normalmente, ele usará um UUID para o sistema de arquivos (se o sistema de arquivos tiver tal coisa) ou o número do dispositivo que contém o sistema de arquivos (se o sistema de arquivos estiver armazenado no dispositivo). Como nem todos os sistemas de arquivos são armazenados em dispositivos, e nem todos os sistemas de arquivos têm UUIDs, às vezes é necessário informar explicitamente ao NFS como identificar um sistema de arquivos. Isso é feito com a opção fsid =.

Para o NFSv4, existe um sistema de arquivos distinto, que é a raiz de todo o sistema de arquivos exportado. Isso é especificado com fsid = root ou fsid = 0, ambos significam exatamente a mesma coisa.

Outros sistemas de arquivos podem ser identificados com um inteiro pequeno, ou um UUID que deve conter 32 dígitos hexadecimais e pontuação arbitrária.

Os kernels Linux versão 2.6.20 e anteriores não entendem a configuração UUID, portanto, um inteiro pequeno deve ser usado se uma opção fsid precisar ser configurada para tais kernels. A configuração de um número pequeno e de um UUID é suportada para que a mesma configuração possa ser feita para funcionar tanto em kernels antigos quanto em novos.