Ficar desconectado de uma sessão SSH mata seus programas?

Então, digamos que eu seja desconectado de uma sessão SSH após iniciar rsyncou cpou qualquer outro comando que possa demorar muito tempo. Esse comando continua em execução até terminar após eu ser desconectado ou simplesmente ser morto?

Sempre me perguntei isso.

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.

Como outros já mencionaram, uma vez que você se desconecta do ssh, tudo o que está em execução desaparece.

Como o @Michael Hampton e outros mencionaram, você pode usar ferramentas como tmuxou screendesconectar / reconectar-se aos terminais sem perder seu conteúdo (por exemplo, processos filhos).

Além disso, você pode colocar um processo em segundo plano usando um &e comercial e, em seguida, usar o comando disownpara desassociá-los com o shell atual.

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

Não, qualquer programa ainda conectado ao terminal, e não colocado em segundo plano com algo parecido nohup, seria eliminado.

É por isso que existem soluções de terminal virtual, como tmuxa anterior, screenque criam sessões que continuam em execução, mesmo se você estiver desconectado, e às quais você pode reconectar posteriormente.