Co stanie się z wynikiem procesu, który został odrzucony i stracił swój terminal?

Jeśli zamknę wirtualny terminal, w którym uruchomiono jakiś proces, to czy dane wyjściowe po prostu idą prosto do /dev/null, czy może w jakiś sposób zanieczyszczają pamięć? Czy w jakikolwiek sposób mogę pobrać dane wyjściowe i kontynuować czytanie w dowolnym momencie?

[EDYCJA]: Czy zatem moment wyparcia się procesu jest końcem mojej mocy kontrolowania jego wyników?

Zauważyłem również, że jeśli odrzucę zatrzymany proces, na początku wszystko wydaje się normalne: nie jest zakończone ani pokazane w zadaniach. Ale jeśli się wyloguję (i nie mam na myśli zamknięcia terminala, po prostu suna przykład wyjdź z ), proces zostanie zakończony. Mimo to odrzucony proces działający w tle może pozostać uruchomiony.

Fakt „odrzucenia” procesu ma znaczenie tylko dla interaktywnej powłoki, która go utworzyła. Oznacza to, że powłoka nie zawiera (już) procesu w tabeli zadań i że SIGHUP nie zostanie wysłany do tego procesu po wyjściu powłoki. To nie jest tak naprawdę związane z twoimi pytaniami.

O tym, co dzieje się z wyjściami wysyłanymi do usuniętego wirtualnego terminala: sam wykonałem kilka testów i zauważyłem, że /dev/pts/xurządzenia nie są dostępne i nie zostaną przydzielone ponownie, dopóki wszystkie deskryptory plików, które na nie wskazują, nie zostaną zamknięte. Nie widzę więc powodu, dla którego zapisy do usuniętego terminala byłyby przechowywane. Myślę, że nie jest to nawet zdefiniowane przez POSIX.

Jeśli chodzi o pobieranie wyników jakiegoś procesu, który zapisuje na terminalu, nie sądzę, że jest to możliwe, nawet gdy terminal wciąż żyje¹. Wszystko, co możesz zrobić, to pobrać bezpośrednie wejście do terminala (tj. Naciśnięcia klawiszy lub symulowane naciśnięcia klawiszy przez część główną pty). Gdyby procesy odczytywały na standardowym to, co zapisywane są na ich terminalach, dla większości procesów prowadziłoby to do pętli self io.

Jeśli chodzi o ostatnią uwagę na temat zakończenia procesu, tak naprawdę nie wiem, co się dzieje, ale podejrzewam raczej dziwne zachowania z sygnałami (SIGTTOU, SIGTTIN, SIGHUP lub innymi) związane ze stanem pierwszego planu / tła grup procesów, gdy sesja lider kończy (np. suwe wspomnianym przypadku).

Odpowiedź na edycję: Nie, jeśli chodzi o dane wyjściowe, nic się nie zmienia, gdy proces jest odrzucany: nadal jest przyłączony do terminala sterującego (chyba że odłączył się już tak jak demony). Możesz to zobaczyć za pomocą ps. Jednak nie będziesz już mógł używać poleceń fg/ bg/ jobsdostarczonych przez powłokę dla tego procesu. Oznacza to, że podawanie danych wejściowych z terminala może być trudne (wymaga przynależności do grupy procesów pierwszego planu).

-
^{1. chyba że proces jest skłonny lub przejęty za pomocą niektórych narzędzi do debugowania (patrz komentarze powyżej).}

Wystarczy odpowiedzieć na to konkretne pytanie:

Jeśli zamknę wirtualny terminal, w którym uruchomiono jakiś proces, to czy dane wyjściowe przechodzą prosto do / dev / null, czy może w jakiś sposób skazić pamięć?

Terminal i podłączony program łączą się za pośrednictwem urządzenia tty, odczytując i zapisując go jak plik. W szczególności terminal wirtualny tworzy „pseudo-tty” (w skrócie „pty”), a następnie spawnuje proces powłoki (lub inny) i łączy stdin / out / err tego procesu z pty. (Szczegóły różnią się w zależności od systemu operacyjnego).

Po zamknięciu wirtualnego terminala, wirtualny terminal zamyka swój koniec połączenia (pty „master”). Następnie, jeśli program na drugim końcu połączenia zapisuje do tty, zwracany jest błąd i dane nigdzie nie trafiają. Podobnie, jeśli odczyta z tty, zwróci wskaźnik EOF (koniec pliku).

Aby odpowiedzieć na najciekawszą część pytania: aby zmienić wyjście uruchomionego programu na żywo, musisz edytować deskryptory plików. Z gdb jest to dość łatwe. To hack, ale działa.

Widzieć:

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

Skrypt pomocnika jest dostępny na stronie http://users.linpro.no/ingvar/fdswap.sh.txt .

Dzięki komentarzowi Gillesa, który skierował mnie do tego pytania , dowiedziałem się o programie o nazwie retty .

Wydaje się, że używa jakiegoś brudnego hacka, aby ponownie połączyć się z (pseudo-) tty skutecznie, pozwalając na dalsze czytanie wyniku procesu - bez względu na to, czy został odrzucony, czy nie. To wydaje się odpowiadać na większość pierwszej części mojego pytania. Na drugie odpowiedział Stéphane .