Retomar o comando em execução na sessão SSH descartada

Question

Ler esta pergunta me fez pensar. Assumindo que screen não esteja sendo usado. Se uma sessão SSH em um destino Linux for descartada, por qualquer razão, e você reconectar antes que o servidor mate a sessão por causa do tempo limite, é possível recuperar o controle do comando em execução de forma que ele não seja abortado por causa da sessão quebrada ?

    

Answer 1

A tentativa de conectar os descritores de arquivos STD * atuais de um novo terminal a um processo antigo está apenas causando problemas. Mesmo se você conseguir fazer isso, o controle do trabalho do terminal não funcionará como esperado. Você terá uma bagunça deixada para trás se, eventualmente, sair do programa, e o que acontece com o shell que sacrificou seus descritores de arquivo para serem entregues ao novo processo de segundo plano. O ssh ficará aberto quando a casca desaparecer? Provavelmente não. Então, você precisará redirecioná-lo para outro lugar primeiro.

Possível ou não, eu aposto que é mais desejável deixar o processo abandonado ser morto "naturalmente". Se você está fazendo algo importante o suficiente para justificar a tentativa de fazer todo o hackery necessário para retomar o controle e você está em um link instável, você provavelmente deve saber isso antes e usar apenas a tela (ou vnc , ou o que flutua seu barco de controle destacado). :)

    

Answer 2

Eu sei que essa é uma pergunta antiga, mas senti que é importante adicionar minhas descobertas no caso de alguém se deparar com isso, como eu fiz.

Eu não vi nenhuma conseqüência incomum em fazer isso sim, mas é isso que eu usei e funcionou de maneira surpreendente. Às vezes, quando executamos longos processos em nosso servidor, ele ocasionalmente desconectará a sessão ssh. O processo junto com a sessão tty parece continuar funcionando, mas não podemos nos reconectar a ele. Eu encontrei o programa abaixo para puxar o processo para a sessão recém-conectada.

link

Veja mais informações

link

    

Answer 3

Geralmente, a maneira correta de lidar com isso é se preparar antecipadamente, usando os mecanismos GNU screen ou bash nohup ou disown . Se você estiver usando tcsh , o shell rejeitará trabalhos em segundo plano quando ele sair anormalmente.

Se você não estiver usando screen , mas conseguir manter seu processo em execução por meio de um dos métodos rejeitar , poderá ser capaz de se reconectar ao processo com gdb (< uma fonte do href="http://dbaspot.com/forums/shell/369353-move-process-screen.html#post1240120"> ):

[...] with some dirty hacks, it is not impossible to reopen a process' stdout/stderr/stdin. [...]

And then use gdb for instance to attach to the process, do some call close(0)
call close(1)
call close(2)
call open("/dev/pts/xx", ...)
call dup(0)
call dup(0)
detach

Agora, você teria que ajustar esse processo para sua situação. Eu duvido que ajudaria se você não conseguisse negar o processo. Se você estiver usando bash , veja esta postagem sobre como fazer bash automaticamente rejeita os processos em segundo plano ao sair (basicamente, desative huponexit com shopt ). Com um processo em primeiro plano, você precisa ter usado nohup .

    

Answer 4

Provavelmente não. Eu não posso garantir que é impossível, mas eu realmente duvido.

Uma coisa é a falta de matar o shell e possíveis comandos executados como conseqüência do término da conexão ssh. Isso não é tão difícil, você deve ser capaz de usar nohup e mecanismos semelhantes, como mencionado na outra questão.

Mas, suponha que você tenha iniciado ssh somehost nuhup vim /some/file e a conexão falhe. Você executa ssh somehost para efetuar login novamente e pode ver que seu processo de vim ainda está em execução. Mas então, como você se conecta a esse processo novamente? Processos interativos forground têm um controle tty e o que foi aberto para o seu processo de vim quando começou, desde então foi fechado. Não tenho certeza se há alguma maneira de "reabri-lo" novamente em seu novo shell (como se você tivesse várias tarefas em segundo plano em execução em um shell, não é possível forçar nenhuma delas em outro shell).

Screen foi explicitamente escrito para ter essa funcionalidade. Na inicialização, ele bifurca dois processos, um processo de gerenciamento de terminal e um processo de cliente. A interação é cliente < - > gestor de terminais < - > aplicativo, e quando você desconecta ou perde a conexão, o processo do cliente é interrompido enquanto o gerente do terminal continua a viver. A tela tem algum suporte específico para anexar ao processo de gerenciamento do terminal novamente mais tarde, e eu não acho que isso seja possível no caso geral.

    

Answer 5

retty pode ajudá-lo, mas as isenções de responsabilidade são muito reais e relevantes:)

    

Answer 6

Se session for eliminado, isso significa que o TTL já expirou, portanto não há mais tty para você (pelo que entendi). Mas, se sua conexão de rede for interrompida, sua sessão SSH pode não precisar ser interrompida, e você poderá continuar sua conexão e continuar. É sobre isso que você está perguntando?

    

Answer 7

Houve um link para algum código hacky tty de furto em esta pergunta . Você deveria, teoricamente, ser capaz de usar isso para recuperar o controle de um processo nohup.