Voici le scénario hypothétique: Je cours un script de test sur du matériel attaché à la boîte A, auquel j'ai un accès root. Ce script de test nécessite une intervention minimale de l'utilisateur (basculer un commutateur toutes les demi-heures environ). Environ une heure et demie dans le processus de test, je me rends compte que ce script prend beaucoup de temps à terminer, au rythme de huit heures. La boîte A est située dans une salle de serveur très froide et bruyante qui n'est généralement pas très amusante à occuper physiquement. La boîte B est située dans mon bureau, où j'ai une belle chaise confortable et un approvisionnement sans fin de poches chaudes. Je veux un moyen de surveiller la sortie du processus qui s'exécute sur la boîte A à partir d'une session SSH dans la boîte B afin que je sache quand retourner le commutateur, mais je ne veux pas redémarrer le processus de test. Si j'avais su au début que le test prendrait tant de temps à se terminer, j'aurais simplement redirigé sa sortie vers un fichier journal et aurais jeté ce fichier depuis ma session ssh de la boîte B. Si je connais le PID du processus qui s'exécute sur la case A, est-il possible d'observer la sortie standard de ce processus à partir d'une autre session?observation stdout d'un autre processus
Bien sûr, je pourrais simplement lancer vnc sur la case A et me connecter à partir de la case B pour voir la sortie, mais cela va à l'encontre de cet objectif, qui est d'en apprendre plus sur la façon dont les et sortie en général dans un environnement Linux.
Pensées?
C'est exactement ce que j'espérais trouver! Merci - je n'avais même pas envisagé d'utiliser gdb pour détourner le descripteur de fichier du processus. –