Esta é uma questão que foi abordada várias vezes, não apenas aqui, mas também em outros sites da rede de troca de pilha (por exemplo, Como fazer ssh para matar o processo remoto quando eu interromper o próprio ssh? ). No entanto, não posso fazer nenhuma das soluções funcionar para mim.
Estou executando um comando por meio do ssh. Sempre que saio do ssh, quero que o comando morra também. Este comando é um daemon chamado ktserver que é executado indefinidamente até você pressionar Ctrl-C.
Eu o corro assim: ssh -t compute-0-1 ktserver e, na verdade, quando pressiono Ctrl-C, o processo termina normalmente e a sessão ssh termina.
No entanto, se em vez de pressionar Ctrl-C, eu mato o processo ssh usando o comando kill (por exemplo, enviando SIGINT ou SIGHUP), o processo ktserver permanece ativo.
Como posso fazer com que o ktserver sempre morra independentemente de como ssh é eliminado?
EDIT : Se, em vez de ktserver executar algo completamente diferente, como gedit , tudo funciona como um encanto (ou seja, o gedit morre quando a conexão morre). Portanto, pode haver algo errado com o processo em si. Por exemplo, achei que poderia estar ignorando o SIGHUP ou o SIGINT. No entanto, quando executo kill -1 ktserver ou kill -2 ktserver , o processo morre conforme esperado.
EDIT2 : Como assinala Mark Plotnick, a questão está relacionada ao fato de que não há comunicação circulando no canal ssh. Eu confirmei executando ssh -t <host> read e matando o processo ssh depois. read ainda estava vivo e chutando.
Normalmente, quando a conexão ssh morre, o shell também morre. Você pode configurar seu shell para enviar um sinal -1 (SIGHUP) quando ele terminar para todos os seus filhos.
Para o bash você pode configurar esta opção através do comando shopt . ( shopt -s huponexit ).
Para o zsh, você deseja setopt HUP .
Descobri que simplesmente usar -t -t como um argumento para ssh fez com que funcionasse. Não precisei definir huponexit para o shell de origem ou remoto.
Eu testei isso da seguinte forma:
ssh user@remote sleep 100
^C
Isso matou a sessão ssh, mas posso ver que o processo de suspensão ainda está sendo executado no host remoto ( ps -ef | grep sleep mostra isso).
ssh -t -t user@remote sleep 100
^C
Isso mata a sessão ssh e o processo de suspensão remota também foi eliminado. Eu também verifiquei que o sinal que é enviado para o processo remoto é SIGINT se você usar Controle - C . Também verifiquei que SIGKILL (-9) aplicado ao processo ssh também matará o processo remoto.
Isso era verdadeiro para sleep ... para processos remotos mais teimosos, descobri que ssh manipula ^ C diferentemente que SIGINT. Ctrl - C funcionou, mas kill -INT $pid didn'.t
Aqui está o que eu finalmente criei que funcionou para minha aplicação real (roubar as outras respostas).
ssh -t -t -i id_rsa user@mic0 "/bin/sh -O huponexit -c 'sleep 100'"
Observe o uso aninhado de aspas duplas e aspas simples. Note que o seu processo remoto DEVE responder ao SIGHUP ao realmente sair!
Se o ssh não propagar sinais, ele recebe o que você espera dele?
UPD. (especial para JosephR): obviamente é um erro em questão que resulta de um mal-entendido - "Kill process gerado por ssh quando ssh morre". O SSH não gera processos normalmente (às vezes, mas essa é outra história), o SSHD ao invés, quando olhamos para o outro lado da conexão. SSH meramente confia em abstração pseudo-terminal servidor remoto tem. É por isso que a única coisa que pode ajudar é a capacidade do terminal de emitir sinais para seus processos conectados. Isso é um pouco básico para todo sistema semelhante ao UNIX.
A solução postada aqui não funcionou para mim, mas desde que essa pergunta surgiu primeiro quando eu estava procurando solução para um problema semelhante e também -t -t truque foi mencionado aqui eu vou postar solução que funcionou para mim para os outros tentarem.
ssh -t -t -o ControlMaster=auto -o ControlPath='~/test.ssh' your_remote_ip_goes_here "your_long_running_command" &
sleep 100
ssh -o ControlPath='~/test.ssh' -O exit your_remote_ip_goes_here
Meu comando de longa duração não estava mais em execução quando a conexão foi encerrada dessa forma.