Lecture cette question m'a amené à me poser des questions. En supposant que screen n'est pas utilisé. Si une session SSH sur une cible Linux est interrompue, pour quelque raison que ce soit, et que vous vous reconnectez avant que le serveur ne ferme la session pour cause de dépassement de délai, est-il possible de reprendre le contrôle de la commande en cours d'exécution de manière à ce qu'elle ne soit pas interrompue à cause de la session interrompue ?
Réponses
Trop de publicités?
Tenter de connecter les descripteurs de fichiers STD* d'un nouveau terminal à un ancien processus en cours d'exécution, c'est s'attirer des ennuis. Même si vous y parvenez, le contrôle des tâches du terminal ne fonctionnera pas comme prévu. Vous aurez un désordre laissé derrière vous si vous quittez finalement le programme pris en charge, et ce qu'il advient du Shell qui a sacrifié ses descripteurs de fichiers pour être remis au processus nouvellement mis en arrière-plan. Est-ce que ssh restera ouvert quand cette 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 vous êtes sur un lien instable, vous devriez probablement le savoir à l'avance et utiliser screen (ou vnc, ou tout ce qui peut faire flotter votre bateau de contrôle détaché) :)
Paul
Points
6185
Je sais que c'est une vieille question, mais j'ai pensé qu'il était important d'ajouter mes conclusions au cas où quelqu'un d'autre tomberait sur ce problème comme moi.
Je n'ai pas vu de conséquences inhabituelles à cette façon de faire, mais c'est ce que j'ai utilisé et cela a fonctionné à merveille. Parfois, lorsque nous exécutons de longs processus sur notre serveur, il arrive que la session ssh soit déconnectée. Le processus ainsi que la session tty semblent rester en cours d'exécution 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
user21576
Points
106
En général, la bonne façon de gérer cette situation est de s'y préparer à l'avance, en utilisant GNU screen ou de bash nohup ou disown mécanismes. Si vous utilisez tcsh le Shell désavouera les tâches d'arrière-plan lorsqu'il sortira de façon anormale.
Si vous n'utilisez pas screen mais que vous avez réussi à maintenir votre processus en cours d'exécution via l'une des désavouer vous pourrez peut-être simuler une reconnexion au processus avec gdb ( source ) :
[...] avec quelques bidouillages sales, ce n'est pas impossible de rouvrir un processus stdout/stderr/stdin. [...]
Et ensuite utiliser gdb par exemple pour s'attacher au processus, faire des appel close(0)
appeler close(1)
appeler close(2)
appel open("/dev/pts/xx", ...)
appel dup(0)
appel dup(0)
détacher
Maintenant, vous devez adapter ce processus à votre situation. Je doute que cela puisse aider si vous n'avez pas réussi à désavouer le processus. Si vous utilisez bash , voir ce post sur la fabrication bash automatiquement désavouer les processus d'arrière-plan à la sortie (en gros, éteindre les huponexit avec boutique en ligne ). Avec un processus d'avant-plan, vous devez avoir utilisé nohup .
ColinYounger
Points
2941
Probablement pas. Je ne peux pas garantir que c'est impossible, mais j'en doute vraiment.
Une chose est l'absence de mise à mort du Shell et des éventuelles commandes s'exécutant à la suite de la fin de la connexion ssh. Ce n'est pas si difficile, vous devriez être en mesure d'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/file et la connexion s'interrompt. Vous exécutez ssh somehost pour vous reconnecter et voir que votre processus vim est toujours en cours. Mais alors, comment se reconnecter à ce processus ? Les processus interactifs de fond ont un contrôle tty et celui qui a été ouvert pour votre processus vim au démarrage aurait été fermé depuis. Je ne suis pas sûr qu'il y ait un moyen de le "rouvrir" à nouveau dans votre nouvelle Shell (tout comme si vous avez plusieurs tâches d'arrière-plan en cours d'exécution dans une Shell, vous ne pouvez pas les mettre au premier plan dans une autre Shell).
Screen ont été explicitement écrites pour avoir cette fonctionnalité. Au démarrage, il crée deux processus, un processus de gestion du terminal et un processus client. L'interaction est client <--> gestionnaire de terminal <--> application, et lorsque vous vous détachez ou perdez la connexion, le processus client meurt tandis que le gestionnaire de terminal continue à vivre. Screen dispose d'un support spécifique pour se rattacher à nouveau au processus de gestion de terminal plus tard, et je ne pense pas que cela soit possible dans le cas général.
Evan Broder
Points
821
Retenue pourrait être en mesure de vous aider, mais les avertissements sont très réels et pertinents :)
- Réponses précédentes
- Plus de réponses
0 votes
Quelle est cette commande ? Je suppose que la réponse est généralement non.
0 votes
Pas de commande particulière, je demande juste comme un concept général.
1 votes
Quelqu'un ayant une connaissance approfondie de la manière dont les sessions tty sont initialisées pourra peut-être nous dire comment. Il semble que si vous pouviez recréer une nouvelle session sur le même tty et assigner explicitement le PPID précédent, cela pourrait être possible. J'attends juste qu'un gourou barbu de Nix vienne nous épater. C'est le rêve de toute façon.
0 votes
Que se passe-t-il si vous faites l'expérience d'un ordinateur portable connecté et que vous retirez le cordon Ethernet ?
0 votes
@~drpaulbrewer - Exactement la même chose que lorsque vous faites cela avec une machine de bureau - la connexion est abandonnée. La façon dont la connexion est coupée n'a rien à voir avec la question.