Editar para 2016:
Estas perguntas e respostas são anteriores ao desastre do systemd v230 . No systemd v230, o novo padrão é eliminar todos os filhos de uma sessão de login final, independentemente de quais precauções historicamente válidas foram tomadas para evitar isso. O comportamento pode ser alterada por ajuste KillUserProcesses=noem /etc/systemd/logind.conf, ou contornada utilizando os mecanismos específicos do Systemd para iniciar um daemon no espaço do usuário. Esses mecanismos estão fora do escopo desta questão.
O texto abaixo descreve como as coisas tradicionalmente funcionam no espaço de design do UNIX por mais tempo do que o Linux existe.
Eles serão mortos, mas não necessariamente imediatamente. Depende de quanto tempo leva para o daemon SSH decidir que sua conexão está inoperante. A seguir, é apresentada uma explicação mais longa que o ajudará a entender como ele realmente funciona.
Quando você efetuou login, o daemon SSH alocou um pseudo-terminal para você e o anexou ao shell de login configurado do usuário. Isso é chamado de terminal de controle. Todo programa que você inicia normalmente nesse ponto, não importa quantas camadas de conchas sejam profundas, acabará rastreando sua ancestralidade de volta àquela concha. Você pode observar isso com o pstreecomando
Quando o processo do daemon SSH associado à sua conexão decide que sua conexão está inoperante, ele envia um sinal de interrupção ( SIGHUP) para o shell de login. Isso notifica o shell que você desapareceu e que ele deve começar a limpar depois de si mesmo. O que acontece neste momento é específico do shell (pesquise na sua página de documentação por "HUP"), mas na maioria das vezes ele começará a enviar SIGHUPpara tarefas em execução associadas a ele antes de terminar. Cada um desses processos, por sua vez, fará o que estiver configurado para receber o sinal. Geralmente isso significa terminar. Se esses trabalhos tiverem seus próprios trabalhos, o sinal também será transmitido com frequência.
Os processos que sobrevivem a uma interrupção do terminal de controle são aqueles que se desassociaram de um terminal (processos daemon que você iniciou dentro dele) ou que foram chamados com um nohupcomando prefixado . (ou seja, "não desligue isso") Os daemons interpretam o sinal HUP de maneira diferente; como eles não têm um terminal de controle e não recebem automaticamente um sinal HUP, ele é redirecionado como uma solicitação manual do administrador para recarregar a configuração. Ironicamente, isso significa que a maioria dos administradores não aprende o uso "hangup" desse sinal para não-daemons até muito, muito mais tarde. É por isso que você está lendo isso!
Os multiplexadores de terminal são uma maneira comum de manter intacto o ambiente do shell entre as desconexões. Eles permitem que você se desconecte dos processos do shell de uma maneira que você possa reconectá-los posteriormente, independentemente de essa desconexão ser acidental ou deliberada. tmuxe screensão os mais populares; A sintaxe para usá-los está além do escopo da sua pergunta, mas vale a pena analisar.
Foi solicitado que eu descrevesse quanto tempo leva para o daemon SSH decidir que sua conexão está morta. Esse é um comportamento específico para todas as implementações de um daemon SSH, mas você pode contar com todos eles para terminar quando um dos lados redefinir a conexão TCP. Isso acontecerá rapidamente se o servidor tentar gravar no soquete e os pacotes TCP não forem reconhecidos ou lentamente se nada estiver tentando gravar no PTY.
Nesse contexto específico, os fatores com maior probabilidade de acionar uma gravação são:
- Um processo (normalmente aquele em primeiro plano) tentando gravar no PTY no lado do servidor. (servidor-> cliente)
- O usuário tentando gravar no PTY no lado do cliente. (cliente-> servidor)
- Keepalives de qualquer tipo. Normalmente, eles não são ativados por padrão, nem pelo cliente nem pelo servidor, e geralmente existem dois tipos: nível de aplicativo e baseado em TCP (ou seja
SO_KEEPALIVE). Keepalives equivalem ao servidor ou ao cliente que raramente envia pacotes para o outro lado, mesmo quando nada teria um motivo para gravar no soquete. Embora isso normalmente pretenda evitar firewalls que atingem o tempo limite das conexões muito rapidamente, ele tem o efeito colateral adicional de fazer com que o remetente note quando o outro lado não está respondendo muito mais rapidamente.
As regras usuais para sessões TCP se aplicam aqui: se houver uma interrupção na conectividade entre o cliente e o servidor, mas nenhum dos lados tentar enviar um pacote durante o problema, a conexão sobreviverá, desde que ambos os lados respondam posteriormente e recebam o TCP esperado. números de sequência.
Se um lado decidiu que o soquete está morto, os efeitos são geralmente imediatos: o processo sshd enviará HUPe terminará automaticamente (conforme descrito anteriormente) ou o cliente notificará o usuário sobre o problema detectado. Vale a pena notar que, apenas porque um lado pensa que o outro está morto, não significa que o outro está notificado. O lado órfão da conexão normalmente permanece aberto até que ele tente gravar nela e expire o tempo limite ou receba uma redefinição de TCP do outro lado. (se a conectividade estava disponível no momento) A limpeza descrita nesta resposta ocorre apenas quando o servidor percebe.
screen, tente reptyr .