Qu'arrive-t-il à la sortie d'un processus qui a été renié et a perdu son terminal?

Si je ferme le terminal virtuel, où un processus a été démarré, la sortie va-t-elle directement /dev/nullou peut-elle polluer la mémoire d'une manière ou d'une autre? Puis-je de toute façon récupérer la sortie pour continuer à la lire à tout moment après cela?

[EDIT]: Alors, le moment de renier un processus est-il effectivement une fin de mon pouvoir de contrôler sa sortie?

J'ai également remarqué que si je renie un processus arrêté, tout semble au premier abord normal: il n'est ni terminé ni affiché dans les travaux. Mais si je me déconnecte (et je ne veux pas dire fermer le terminal, juste quitter su, par exemple), le processus est terminé. Néanmoins, un processus non exécuté en arrière-plan peut continuer de fonctionner.

Le fait qu'un processus soit "renié" n'a de sens que pour le shell interactif qui a créé ce processus. Cela signifie que le shell n'inclut pas (plus) le processus dans sa table de jobs, et que SIGHUP ne sera pas envoyé à ce processus lorsque le shell se fermera. Ce n'est pas vraiment lié à vos questions.

À propos de ce qui arrive aux sorties envoyées à un terminal virtuel supprimé: j'ai fait moi-même des tests et j'ai remarqué que les /dev/pts/xpériphériques ne sont pas accessibles et ne seront pas alloués à nouveau tant que tous les descripteurs de fichiers qui les désignent n'ont pas été fermés. Donc, je ne vois pas pourquoi les écritures sur un terminal supprimé seraient stockées. Je suppose que ce n'est même pas défini par POSIX.

À propos de la capture de la sortie d'un processus qui écrit sur un terminal, je ne pense pas que ce soit possible, même lorsque le terminal est toujours en vie¹. Tout ce que vous pouvez faire est de saisir l'entrée directe du terminal (c'est-à-dire les frappes ou les frappes simulées par la partie principale d'un pty). Si les processus lisaient sur stdin ce qui est écrit sur leurs terminaux, cela conduirait à une boucle auto io pour la plupart des processus.

À propos de la dernière remarque sur l'arrêt du processus, je ne sais pas vraiment ce qui se passe, mais je soupçonne des comportements plutôt étranges avec des signaux (SIGTTOU, SIGTTIN, SIGHUP ou autres) liés à l'état de premier plan / d'arrière-plan des groupes de processus, lorsque la session le leader quitte (par exemple su, dans le cas que vous avez mentionné).

Réponse à l' édition: Non, en ce qui concerne la sortie, rien ne change quand un processus est renié: il est toujours attaché à son terminal de contrôle (à moins qu'il ne se détache déjà comme le font les démons). Vous pouvez le voir en utilisant ps. Cependant, vous ne pourrez plus utiliser les commandes fg/ bg/ jobsfournies par le shell pour ce processus. Cela signifie qu'il peut être difficile de l'alimenter avec les entrées du terminal (nécessite d'être dans le groupe de processus de premier plan).

-
^{1. à moins que le processus ne le veuille ou ne le détourne avec certains outils de débogage (voir les commentaires ci-dessus).}

Pour répondre à cette question spécifique:

Si je ferme le terminal virtuel, où un processus a été démarré, la sortie va-t-elle directement à / dev / null, ou peut-elle polluer la mémoire d'une manière ou d'une autre?

Le terminal et le ou les programmes qui lui sont connectés communiquent via un périphérique tty en le lisant et en l'écrivant comme un fichier. Plus précisément, un terminal virtuel crée un "pseudo-tty" ("pty" pour faire court), puis génère un processus shell (ou autre) et connecte le stdin / out / err de ce processus au pty. (Les détails varient selon le système d'exploitation.)

Lorsque vous fermez le terminal virtuel, le terminal virtuel ferme son extrémité de la connexion (le pty "master"). Après cela, si le programme à l'autre extrémité de la connexion écrit sur le tty, une erreur est renvoyée et les données ne vont nulle part. De même, s'il lit à partir du tty, il récupérera un indicateur EOF (fin de fichier).

Pour répondre à la partie la plus intéressante de votre question: pour modifier la sortie d'un programme en cours d'exécution, vous devez modifier ses descripteurs de fichiers. C'est assez facile à faire avec gdb. C'est un hack, mais ça marche.

Voir:

/programming/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-line

Un script d'aide est disponible à http://users.linpro.no/ingvar/fdswap.sh.txt .

Grâce au commentaire de Gilles, me pointant sur cette question , j'ai appris l'existence d'un programme appelé retty .

Il semble utiliser un hack sale pour se rattacher à un (pseudo-) tty permettant effectivement de continuer à lire la sortie d'un processus - qu'il ait été renié ou non. Cela semble donc répondre à la plupart de la première partie de ma question. Le second a été répondu par Stéphane .