Solution 1 :
Tenter de connecter les descripteurs de fichiers STD* actuels d'un nouveau terminal à un ancien processus en cours d'exécution ne fait que créer des ennuis. 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 pris en charge, et ce qui arrive au shell qui a sacrifié ses descripteurs de fichiers pour être remis au processus nouvellement 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 simplement laisser le processus abandonné se faire tuer "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 utilisez simplement screen (ou vnc, ou tout ce qui flotte sur votre bateau de contrôle détaché). :)
Solution 2 :
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 dessus 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é à merveille. Parfois, lorsque nous exécutons de longs processus sur notre serveur, cela déconnecte occasionnellement la session ssh. Le processus et la session tty semblent continuer à fonctionner, mais nous ne pouvons pas nous y 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/
Solution 3 :
Généralement, la bonne façon de gérer cela est de s'y préparer à l'avance, en utilisant GNU screen ou le nohup de bash ou disown mécanismes. Si vous utilisez tcsh , le shell désavouera les tâches en arrière-plan lorsqu'il se fermera de manière anormale.
Si vous n'utilisez pas screen mais avez réussi à maintenir votre processus en cours d'exécution via l'un des disown méthodes, vous pourrez peut-être simuler une reconnexion au processus avec gdb (source):
[...] certains 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 quelque chose appelez close(0)
clôture d'appel(1)
fermer l'appel(2)
call open("/dev/pts/xx", ...)
appel dup(0)
appel dup(0)
détacher
Maintenant, vous devrez ajuster ce processus à votre situation. Je doute que cela vous aide si vous n'avez pas réussi à renier le processus. Si vous utilisez bash , voir ce post sur la création de bash désavouer automatiquement processus d'arrière-plan à la sortie (en gros, désactivez huponexit avec boutique ). Avec un processus de premier plan, vous devez avoir utilisé nohup .