Что происходит с выводом процесса, который отрицали и потерял его терминал?

Только рассмотреть этот конкретный вопрос:

Если я закрываю виртуальный терминал, где некоторый процесс был запущен, вывод просто переходит прямо к/dev/null, или он может загрязнить память так или иначе?

Терминал и программа (программы), подключенная к нему, связываются через tty устройство путем чтения и записи его как файл. А именно, виртуальный терминал создает "pseudo-tty" ("имущество", если коротко) и затем порождает оболочку (или другой) процесс и соединяет stdin/out/err того процесса к имуществу. (Детали варьируются операционной системой.)

При закрытии виртуального терминала виртуальный терминал закрывает свой конец соединения (имущество "ведущее устройство"). После этого, если программа в другом конце соединения пишет в tty, ошибка возвращается, и данные не идут никуда. Точно так же, если это будет читать из tty, то это возвратит EOF (конец файла) индикатор.

То, что процесс "отрицают", имеет только значение для интерактивной оболочки, которая создала этот процесс. Это означает, что оболочка не включает (больше) процесс в свою таблицу заданий, и что SIGHUP не будет отправлен в этот процесс, когда оболочка выйдет. Это действительно не связано с Вашими вопросами.

О том, что происходит с выводами, которые отправляются на удаленный виртуальный терминал: Я сделал некоторые тесты сам, и я заметил это /dev/pts/x устройства не доступны, и не будут выделены снова, пока все filedescriptors, которые указывают им, не были закрыты. Так, я не вижу причины, почему записи к удаленному терминалу были бы сохранены. Я предполагаю, что это даже не определяется POSIX.

О захвате вывода некоторого процесса, который пишет в терминал, я не думаю, что это возможно, даже когда терминал является все еще живым ¹. Все, что можно сделать, захватывает прямой вход к терминалу (т.е. нажатия клавиш или моделируемые нажатия клавиш основной частью имущества). Если процессы считали бы на stdin, что записано в их терминалы, которые привели бы к сам io цикл для большей части процесса.

О последнем комментарии по завершению процесса я действительно не знаю то, что происходит, но я подозревал бы довольно странные поведения с сигналами (SIGTTOU, SIGTTIN, SIGHUP или другие) связанный с состоянием переднего плана/фона групп процесса, когда лидер сессии выходит (например. su, в случае Вы упомянули).

Ответ на Редактирование: Нет, относительно вывода ничто не изменяется, когда процесс отрицают: это все еще присоединено к своему терминалу управления (если это уже не отсоединило себя как демоны, делают). Вы видите то использование ps. Однако Вы не сможете использовать fg/bg/jobs команды, обеспеченные оболочкой больше для этого процесса. Это означает, что могло бы быть трудно питаться, это с входом от терминала (требует, чтобы быть в группе приоритетного процесса).

—
^{1. если процесс не готов, или угнанный с некоторыми средствами отладки (см. комментарии выше).}

Благодаря комментарию Gilles, указывая на меня на этот вопрос, я узнал о программе, названной крысиной.

Это, кажется, использует некоторый грязный взлом для повторного прикрепления к (псевдо-) tty эффективно позволяющий продолжать читать вывод процесса - неважно, отрицали ли это или нет. Таким образом, это, кажется, отвечает на большую часть первой части моего вопроса. Второму ответил Stéphane.

Ответить на самую интересную часть Вашего вопроса: для изменения вывода живой запускающей программы необходимо отредактировать ее дескрипторы файлов. Это довольно легко сделать с gdb. Это - взлом, но работы.

См.:

https://stackoverflow.com/questions/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-line

Сценарий помощника доступен по http://users.linpro.no/ingvar/fdswap.sh.txt.