Não é possível conectar-se ao ssh após o problema do nfs

Question

Eu tive um problema ontem com um servidor que perdeu a conexão (S1). A partir desse servidor, havia um diretório compartilhado com o NFS para outro (S2), sem homedir e não no $ PATH, mas um dir para armazenar arquivos antigos para arquivamento. O S1 voltou a ficar online após algumas horas, mas agora não consigo acessar o S2 por causa disso (e tenho certeza de que é por causa disso, porque todos os outros serviços estão em execução sem nenhum problema). A conexão ssh trava aqui: debug1: Entrando na sessão interativa. Eu sei que um reboot fará o trabalho, mas considerando que este é o NAS de um grande aplicativo, meus chefes vão me matar se eu fizer isso. Existe alguma outra maneira de superar isso? Eu tentei com usuários diferentes, mas todos eles estão no mesmo lugar. Eu me conectei com o HP iLO e nem mesmo lá eu não posso usar meu nome de usuário.

Obrigado antecipadamente.

    

Answer 1

(Você não tem, por acaso, diretórios automontados no S2, não é?)

Tente usar o ssh sem uma sessão interativa:

$ ssh -tvv you@S2 /usr/bin/env MAILCHECK=0 MAIL=/dev/null MAILPATH=/dev/null sh

O "-vv" tem saída extra ssh print - não pode prejudicar - e o "-t" diz para alocar um TTY mesmo que esteja executando um comando ao invés de iniciar um shell interativo. O comando env, define um monte de variáveis de ambiente MAIL * para nada, o que pode ser útil para saber se você tem mail-on-NFS e, finalmente, lança um shell simples.

Alternativamente, tente HOME=/ /bin/su - em vez do sh , se apropriado.

Se você entrar, definitivamente tente desmontar as montagens do NFS. Se falhar (provavelmente), tente com -f . Se isso falhar (ainda é provável), o Linux tem uma opção -l para fazer uma desmontagem lenta: ela desanexará o ponto de montagem da árvore do sistema de arquivos, o que deve tornar os novos processos responsivos. No entanto, todos os processos existentes ainda serão suspensos e não há como evitar isso, exceto a reinicialização.

    

Answer 2

Se eu ler o seu relatório de mensagens: Um usuário está tentando ssh para user @ S2 S2 monta um sistema de arquivos a partir do S1 S1 anteriormente teve um problema que causou um erro de NFS ocorrido no S2. O sistema de arquivos montado no S2 NÃO é um diretório inicial.

Você está usando um automontador? É este linux ou algum outro sabor do UNIX?

Esse tipo de problema faz sentido se a montagem do NFS ausente for um diretório inicial ou acessada de alguma forma durante o processo de login do usuário - o processo de login tenta acessar esse diretório e fica preso na espera do disco. Como a autenticação está dando certo, praticamente tem que ser um desses problemas.

Então você tem 1000% de certeza de que o diretório pessoal do usuário não é NFS? Se não for, você deve ser capaz de ler os arquivos de ponto do usuário no S2 fazendo o login no sistema como root e checando as instâncias onde eles interagem com o problemático sistema de arquivos NFS

Você deve poder verificar fazendo login no sistema como root (via console do iLO se nada mais) e faça um: ps auxww | grep D

Você pode entrar no sistema como root correto? Ou há algo que eu não entendo?

Forçar uma desmontagem e, em seguida, reiniciar os processos NFS no S2 e, em seguida, remontar, deve corrigir isso, embora você possa ter vários processos paralisados que não desaparecerão até a reinicialização.