vim congela via SSH? Verifique o stty antes de culpar a VPN
Um editor congelado via SSH costuma ser um problema de estado do terminal, não um túnel caído. Leia o stty no pseudo-terminal correto e repare apenas esse.
Sessões como esta permanecem ligadas enquanto o editor inicia, e depois o ecrã para de atualizar embora o processo SSH esteja claramente vivo. Escrever não produz nada, Ctrl-C parece não fazer nada, e a conclusão óbvia é que a VPN deixou cair algo. Na maioria das vezes o túnel está bem e o pseudo-terminal remoto está num estado que ninguém pretendia, porque o eco, a entrada canónica e o controlo de fluxo vivem no terminal e não na rede. Descobrir qual dos três se deslocou é um trabalho de dois comandos.
O congelamento vive no terminal, não no túnel
Um pseudo-terminal transporta mais do que bytes. Contém indicadores de disciplina de linha que decidem se a entrada é ecoada, se as leituras esperam uma nova linha, se certos caracteres geram sinais e se a saída pode ser parada por um caractere de controlo. Um editor interativo coloca esse terminal em modo cru durante toda a duração e deveria restaurar as definições anteriores ao sair. Quando a restauração não acontece, a shell para onde voltes não é a shell que deixaste, mesmo que a ligação nunca tenha caído.
Compara os terminais antes de concluir nada. Uma segunda sessão com o mesmo editor prova que o cliente e o caminho conseguem fazer o trabalho; não diz nada sobre o terminal cujos indicadores estão estragados.
Lê as definições no terminal que congelou
Identifica primeiro o dispositivo e depois lê as duas formas do seu estado. A forma legível mostra o que está definido, e a forma de máquina é a que podes voltar a introduzir mais tarde.
tty
stty -a
stty -g
Três grupos de indicadores explicam a maioria destes relatórios. As definições de eco decidem se as teclas aparecem de todo, por isso um terminal com o eco desligado parece morto enquanto a shell recebe cada caractere. O modo canónico decide se um programa vê a entrada linha a linha, por isso um terminal deixado em modo canónico faz uma aplicação em modo cru parecer ignorar as teclas até Enter. As definições de controlo de fluxo decidem se o terminal obedece aos caracteres XON e XOFF, e esse grupo produz o congelamento falso mais convincente dos três.
Regista a saída antes de mudar alguma coisa, sobretudo quando a sessão traz combinações de teclas personalizadas de que alguém depende. A forma de máquina é o registo mais seguro, com a ressalva de que depende da implementação e deve ser restaurada pelo mesmo tipo de sistema que a produziu.
Repara esse terminal, não a sessão em que escreves
A reparação padrão restaura o perfil saudável que a página do manual lista, e afeta apenas um terminal. Se o editor ainda tiver trabalho não guardado nesse terminal, deixa-o em paz até o trabalho ser guardado.
A partir de outra shell, aponta explicitamente ao dispositivo congelado para que o terminal em que trabalhas fique intacto.
stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane
Um ecrã vazio com uma visualização corrompida é um problema diferente de uma disciplina de linha partida, e o programa reset trata disso emitindo sequências de inicialização do terminal. Tenta primeiro a reparação do estado, porque muda definições que podes inspecionar, enquanto a sequência reset reescreve o ecrã e não explica nada sobre como se estragou.
A armadilha Ctrl-S por trás de um congelamento convincente
Quando o controlo de fluxo por software está ativo e os caracteres habituais estão atribuídos, Ctrl-S diz ao terminal para parar de enviar saída e Ctrl-Q diz-lhe para continuar. A sessão mantém-se viva todo o tempo, um único Ctrl-Q é muitas vezes toda a reparação, e nada aparece em nenhum registo, e é assim que este congelamento sobrevive a tantas escaladas.
Inspeciona as definições reais em vez de as assumir. Os caracteres de início e paragem podem ser reatribuídos ou desativados, e um terminal com o controlo de fluxo desligado não reage a nenhum deles.
Se o estado voltar, ou o próprio SSH encravar
Um estado mau recorrente aponta para algo que muda os indicadores sem os restaurar: um ficheiro de arranque, um script invólucro, um multiplexador que reinicia a janela errada ou uma aplicação que morre a segurar o modo cru. Adiciona uma verificação condicional que informe o estado em vez de um reinício incondicional, porque um reinício geral esconde a causa e pode sobrepor-se a definições deliberadas.
Quando o tráfego SSH normal também encrava, ou a reparação não muda nada, o terminal deixa de ser o suspeito.
ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com
Um bloqueio que só aparece durante transferências grandes sugere um problema de MTU no caminho, enquanto um que também engole pressões isoladas aponta para o caminho ou o servidor e não para o tamanho do pacote. Mantém as provas do terminal separadas das provas da rede, porque um editor a funcionar numa segunda sessão não é prova de que o primeiro terminal alguma vez estivesse saudável.