ssh comando de outra máquina

Question

Então, eu estou "instruindo" um comando (que por sinal é um script) dentro de um script da máquina A para a máquina B sobre o ssh e o enviou para o segundo plano. O comando é algo assim: ssh -T MACHINEB SCRIPT &

Eu não tenho um tempo limite no script que é executado na máquina A. Às vezes, tenho notado que a instrução do comando / script existe na máquina B (se eu fizer um ps por ele) mas está meio que travando. O ps mostra o PID e o PPID corretos mas é isso, ele não é concluído.

Estou tentando descobrir o que poderia causar a interrupção do processo. Quer dizer, eu tenho quase certeza de que o código está relacionado, eu só quero descartar a seguinte possibilidade e qualquer outra coisa que vocês possam adicionar.

Quando executo uma execução remota de script ssh, meu processo está anexado à sessão ssh? Então, se eu tenho um problema de rede ou ssh de A para B, o meu processo é afetado?

Obrigado

    

Answer 1

ssh -T MACHINEB SCRIPT & mantém a conexão SSH em execução enquanto o SCRIPT estiver em execução. Precisa, porque:

1. Se o SCRIPT produzir qualquer saída, o SSH deve retransmiti-lo ao host.
2. Se o SCRIPT ler entrada, o SSH deve retransmiti-lo do host. Isso pode seja um pouco sutil .
3. Quando o SCRIPT sai, o SSH transmite seu status de saída para o cliente e o processo ssh sai com esse status.

Se a conexão cair, isso não afetará o SCRIPT se ele não tentar ler ou gravar em stdin, stdout ou stderr. Como não há terminal envolvido, o SCRIPT não será morto por um SIGHUP quando a conexão for interrompida. No entanto, se o SCRIPT tentar, digamos, imprimir uma mensagem de erro, essa mensagem passará pela conexão.

Você deve fazer uma de duas coisas.

• Método de trabalho em lote: certifique-se de que o SCRIPT não receba nenhuma entrada e esteja registrando a saída padrão e o erro padrão em um arquivo.

  ssh -T MACHINEB 'myprogram </dev/null >myprogram.log 2>&1'
  

• Método interativo: execute o SCRIPT dentro de um multiplexador de tela: Tela ou tmux .

  ssh -T MACHINEB screen -S somename -dm myprogram
  

  Você pode ver o que seu programa está fazendo anexando a essa sessão de tela.

  ssh MACHINEB screen -S somename -dr
  

  A sessão de tela sai quando o programa é encerrado. Para mantê-lo por perto para ver a saída e os erros do programa, consulte Evitar que a tela do GNU encerre a sessão assim que o script executado terminar

Veja também Execute comandos remotos, desconectando-os completamente a conexão ssh

    

Answer 2

Sua pergunta não é tão clara e um pouco confusa, mas eu tentaria fornecer algumas respostas para esclarecer as coisas para você. Primeiro, observe que o processo ssh é executado no MACHINEA, enquanto o SCRIPT é executado no MACHINEB. Então, o "&" O sinal coloca o processo do comando ssh na MACHINEA em segundo plano - não o processo SCRIPT (shell) executado no MACHINEB. Portanto, o script (primário) no MACHINEA continua a executar os seguintes comandos do script (primário), enquanto o MACHINEB é executado dentro da sessão "ssh" - em primeiro plano no que diz respeito ao MACHINEB. Portanto, se você tiver um problema de conectividade de A a B, o comando ssh não interromperá o script principal da MACHINEA, porque o processo ssh está em execução (possivelmente emperrado) no segundo plano.

    

Answer 3

Quando você executa um script, ele cria um subshell onde o comando é executado. Todos os processos, incluindo os processos em segundo plano que são executados, como o comando ssh, são anexados a essa subpasta. Se a subshell for terminada, o processo em segundo plano também será eliminado. Em vez disso, tente executar o processo ssh como um comando nohup no script 1. Resposta inspirada por: Iniciar um processo em segundo plano a partir de um script e gerenciá-lo quando o script terminar

Os comandos enviados por ssh são anexados ao processo ssh, e o processo ssh deve continuar em execução para que os comandos sejam concluídos. Sair do processo ssh encerrará todos os processos em segundo plano na Máquina B, já que eles estão anexados à subshell criada para o script 2. Nohup também é útil aqui.

Mas como seu processo está sendo executado na Máquina B, mas aparentemente interrompido e não terminado prematuramente, não parece que um término prematuro do processo ssh pareça ser um problema.

Problemas de rede também são improváveis, pois provavelmente terminariam o processo ssh e terminariam os processos em execução na Máquina B. Além disso, se os problemas de rede não forem tão ruins que terminem o processo ssh, eles não devem afetar os processos em execução na Máquina. B. Há provavelmente algo no script 2 na máquina B que está causando o stall. Uma maneira de provar que esta lógica está errada é matar o processo ssh na Máquina A e ver o que acontece na Máquina B.

Finalmente, sua melhor aposta é executar o comando ssh como um processo nohup, como sugerido no link anterior. Além disso, se seus comandos no script 2 não forem dependentes seqüencialmente, eu os executaria usando nohup também. ( link ). Eu estou supondo que nada no script 1 na máquina A é dependente do script 2 em execução com base no fato de que você tem o comando ssh em execução como um processo em segundo plano.