Reprendre la commande en cours d'exécution dans une session SSH abandonnée

La lecture de cette question m'a fait me demander. En supposant qu'il screenn'est pas utilisé. Si une session SSH sur une cible Linux est abandonnée, pour une raison quelconque, et que vous vous reconnectez avant que le serveur ne tue la session en raison du délai d'expiration, est-il possible de reprendre le contrôle de la commande en cours d'exécution de sorte qu'elle ne soit pas abandonnée en raison de la session interrompue ?

Tenter de connecter les descripteurs de fichier STD * actuels d'un nouveau terminal à un ancien processus en cours d'exécution pose simplement des problèmes. Même si vous parvenez à le faire, le contrôle des tâches du terminal ne fonctionnera pas comme prévu. Vous aurez un gâchis si vous quittez finalement le programme repris, et ce qui arrive au shell qui a sacrifié ses descripteurs de fichiers pour être remis au processus nouvellement mis en arrière-plan. Ssh restera-t-il ouvert lorsque ce shell disparaîtra? Probablement pas. Vous devrez donc d'abord le rediriger ailleurs.

Possible ou non, je parierais qu'il est plus souhaitable de laisser le processus abandonné être tué "naturellement". Si vous faites quelque chose d'assez important pour justifier d'essayer de faire tout le piratage nécessaire pour reprendre le contrôle et que vous êtes sur un lien instable, vous devriez probablement le savoir à l'avance et utiliser simplement screen (ou vnc, ou tout ce qui flotte votre détaché) bateau de contrôle). :)

Je sais que c'est une vieille question, mais je pensais qu'il était important d'ajouter mes conclusions au cas où quelqu'un d'autre trouverait cela comme moi.

Je n'ai pas vu de conséquences inhabituelles à faire cela oui, mais c'est ce que j'ai utilisé et cela a fonctionné de manière incroyable. Parfois, lorsque nous exécutons de longs processus sur notre serveur, cela déconnecte parfois la session ssh. Le processus avec la session tty semble continuer mais nous ne pouvons pas nous reconnecter. J'ai trouvé le programme ci-dessous pour tirer le processus vers la session nouvellement connectée.

https://github.com/nelhage/reptyr

Voici plus d'informations

https://blog.nelhage.com/2011/02/changing-ctty/

Généralement, la bonne façon de gérer cela est de s'y préparer à l'avance, en utilisant GNU screenou bash nohupou des disownmécanismes. Si vous utilisez tcsh, le shell désactive les tâches d'arrière-plan lorsqu'il se ferme anormalement.

Si vous n'utilisez pas screenmais avez réussi à maintenir votre processus en cours d'exécution via l'une des méthodes refusées , vous pourriez être en mesure de simuler la reconnexion au processus avec gdb( source ):

[...] avec quelques hacks sales, il n'est pas impossible de rouvrir un processus stdout / stderr / stdin. [...]

Et puis utilisez gdb par exemple pour vous attacher au processus, faites un appel close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
appeler dup (0)
detach

Maintenant, vous devez modifier ce processus pour votre situation. Je doute que cela aiderait si vous n'avez pas réussi à renier le processus. Si vous utilisez bash, voir ce billet de faire bash automatiquement désavouer les processus d'arrière - plan sur la sortie (essentiellement, éteignez huponexit avec shopt ). Avec un processus de premier plan, vous devez avoir utilisé nohup .

Probablement pas. Je ne peux pas garantir que c'est impossible mais j'en doute vraiment.

Une chose est le manque de tuer le shell et les commandes possibles s'exécutant à la suite de la fin de la connexion ssh. Ce n'est pas si difficile, vous devriez pouvoir utiliser nohup et des mécanismes similaires comme mentionné dans l'autre question.

Mais alors, supposez que vous avez commencé ssh somehost nuhup vim /some/fileet que la connexion s'éteint. Vous exécutez ssh somehostpour vous connecter à nouveau et pouvez voir que votre processus vim est toujours en cours d'exécution. Mais alors, comment vous connectez-vous à nouveau à ce processus? Les processus interactifs forground ont un tty de contrôle et celui ouvert pour votre processus vim au démarrage aurait depuis été fermé. Je ne sais pas s'il existe un moyen de le "rouvrir" à nouveau dans votre nouveau shell (tout comme si vous avez plusieurs tâches d'arrière-plan en cours d'exécution dans un shell, vous ne pouvez pas mettre en avant celles de l'autre shell).

Screenont été explicitement écrits pour avoir cette fonctionnalité. Au démarrage, il bifurque deux processus, un processus de gestion de terminal et un processus client. L'interaction est l'application <--> gestionnaire de terminaux <--> client, et lorsque vous vous déconnectez ou perdez la connexion, le processus client meurt pendant que le gestionnaire de terminaux continue de vivre. Screen a un support spécifique à rattacher plus tard au processus de gestion des terminaux, et je ne pense pas que ce soit possible dans le cas général.

retty pourrait être en mesure de vous aider, mais les clauses de non-responsabilité sont très réelles et pertinentes :)

Si la session est abandonnée, cela signifie que TTL est déjà expiré, donc il n'y a plus de tty pour vous (si je comprends bien). Mais, si votre connexion réseau est interrompue, votre session SSH peut ne pas avoir besoin de s'arrêter, et vous devriez pouvoir reprendre votre connexion et continuer. C'est de cela que vous parlez?

Il y avait un lien vers un code de vol hacky tty dans cette question . Vous devriez théoriquement être en mesure de l'utiliser pour reprendre le contrôle d'un processus nohup.