Processus de mise à mort engendré par ssh lorsque ssh meurt

C'est une question qui a été abordée plusieurs fois, non seulement ici, mais aussi dans d'autres sites du réseau d'échange de pile (par exemple, comment faire ssh pour tuer le processus distant lorsque j'interromps ssh lui-même? ). Cependant, je ne peux faire fonctionner aucune des solutions pour moi.

J'exécute une commande via ssh. Chaque fois que je quitte ssh, je veux que la commande meure également. Cette commande est un démon appelé ktserver qui s'exécute indéfiniment jusqu'à ce que vous appuyiez sur Ctrl-C.

Je l'exécute comme suit: ssh -t compute-0-1 ktserveret, en effet, lorsque j'appuie sur Ctrl-C, le processus se termine avec élégance et la session ssh se termine.

Cependant, si au lieu d'appuyer sur Ctrl-C, je tue le processus ssh à l'aide de la killcommande (par exemple, l'envoi de SIGINT ou SIGHUP), le ktserverprocessus reste vivant.

Comment puis-je rendre le ktservertoujours indépendant sur la façon dont sshest tué?

EDIT : Si, au lieu de ktserverlancer quelque chose de complètement différent, comme gedit, tout fonctionne comme un charme (c'est-à-dire que gedit meurt lorsque la connexion s'éteint). Par conséquent, il peut y avoir un problème avec le processus lui-même. Par exemple, j'ai pensé qu'il pourrait ignorer SIGHUP ou SIGINT. Cependant, lorsque j'exécute kill -1 ktserverou kill -2 ktserver, le processus se termine comme prévu.

EDIT2 : Comme le souligne Mark Plotnick, le problème est lié au fait qu'aucune communication ne circule sur le canal ssh. J'ai confirmé en exécutant ssh -t <host> readet en tuant le processus ssh par la suite. readétait toujours en vie et donnait des coups de pied.

Habituellement, lorsque la connexion ssh meurt, le shell meurt également. Vous pouvez configurer votre shell pour envoyer un signal -1 (SIGHUP) lorsqu'il se termine à tous ses enfants.

Pour bash, vous pouvez configurer cette option via la commande intégrée shopt . ( shopt -s huponexit).

Pour zsh vous voulez .setoptHUP

J'ai trouvé cela simplement en utilisant -t -tcomme argument pour le sshfaire fonctionner. Je n'ai pas eu à définir huponexitle shell d'origine ou distant.

J'ai testé cela comme suit:

Ne fonctionne pas:

ssh user@remote sleep 100
^C

Cela a tué la session ssh, mais je peux voir que le processus de veille est toujours en cours d'exécution sur l'hôte distant (le ps -ef | grep sleepmontre).

Fonctionne:

ssh -t -t user@remote sleep 100
^C

Cela tue la session ssh et le processus de veille à distance a également été tué. J'ai également vérifié que le signal envoyé au processus distant est SIGINTsi vous utilisez Control- C. J'ai également vérifié que SIGKILL (-9) appliqué au sshprocessus tuera également le processus distant.

EDIT 1:

C'était vrai pour sleep... pour les processus à distance plus tenaces, je trouve que les sshpoignées ^ C différemment que SIGINT. Ctrl- a Cfonctionné, mais kill -INT $pidn'a pas fonctionné

Voici ce que j'ai finalement trouvé qui a fonctionné pour ma candidature réelle (en volant les autres réponses).

ssh -t -t -i id_rsa user@mic0 "/bin/sh -O huponexit -c 'sleep 100'"

Notez l'utilisation imbriquée des guillemets doubles et des guillemets simples. Notez que votre processus distant DOIT répondre à SIGHUP en quittant réellement!

Si ssh ne propage pas les signaux qu'il reçoit, qu'en attendez-vous?

UPD. (spécial pour JosephR): c'est évidemment une erreur en question elle-même qui découle d'un malentendu - "Kill process engendré par ssh lorsque ssh meurt". SSH ne génère généralement pas de processus (parfois, mais c'est une autre histoire), SSHD le fait à la place, lorsque nous examinons l'autre côté de la connexion. SSH s'appuie simplement sur un serveur distant d'abstraction pseudo-terminal. C'est pourquoi la seule chose qui peut être utile est la capacité du terminal à émettre des signaux vers ses processus attachés. C'est un peu très basique pour chaque système de type UNIX.

La solution publiée ici n'a pas fonctionné pour moi, mais comme cette question est apparue en premier lorsque je cherchais une solution à un problème similaire et -t -tqu'une astuce a également été mentionnée ici, je publierai une solution qui a fonctionné pour moi pour que d'autres puissent l'essayer.

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

Ma commande longue ne fonctionnait plus lorsque la connexion a été interrompue comme ceci.