Dlaczego close_on_exec nie jest domyślną konfiguracją?

Question

Ponieważ wydaje się, że nie ma możliwości użycia już otwartego fd po exec,

dlaczego ta flaga nie jest domyślna?

Answer 1

Ponieważ w systemie UNIX jedną z najczęściej używanych funkcji jest przesyłanie strumieni między procesami - i nie można tego zrobić, jeśli ustawiono flagę CLOEXEC (proces potomny nie może dziedziczyć deskryptorów plików, np .: STDOUT_FILENO).

I nie, nie jest prawdą, że po exec nie można używać odziedziczonych deskryptorów plików (przykład: standardowe strumienie). Możesz także użyć dowolnego odziedziczonego deskryptora pliku, o ile znasz jego wartość (jest to liczba całkowita). Wartość ta jest często przekazywana do procesu potomnego za pomocą argumentu (kilka programów uniksowych to robi) lub można to zrobić w dowolny inny sposób za pomocą dowolnego mechanizmu IPC (komunikacja między procesami) do wyboru.

Answer 2

Deskryptory plików można używać po wywołaniu exec; w ten sposób na przykład narzędzia Unix uzyskują standardowe powłoki wejścia/wyjścia/błędu z powłoki.

Close-on-exec nie jest domyślnym ponieważ POSIX standard (i Unix tradycja) nakazuje odwrotny problem:

deskryptory plików otwarte w obrazie procesu wywołującego będzie otwarta w nowym procesie obrazu, z wyjątkiem dla tych, dla których ustawiono flagę close-on-exec FD_CLOEXEC.

Answer 3

Nie miałbym nic przeciwko uzyskaniu pełniejszej odpowiedzi na to pytanie, ale dość łatwo zgadnąć, że jest kompatybilny wstecz. flaga "near-on-exec" musiała zostać wprowadzona kiedyś. Kod istniejący przed tym czasem nie wiedział o tym i nie działał poprawnie, chyba że został zmieniony. Dlatego domyślnie jest wyłączona.

Niestety, z tego powodu błędy powodują, że proces demona otwierający cgi może pozostawić gniazdo nasłuchiwania otwarte, a jeśli cgi go nie zamknie, to demon nie może zostać uruchomiony ponownie. Zgadzam się z tobą, że to nie jest dobra domena.