Jaki jest powód wykonywania podwójnego rozwidlenia podczas tworzenia demona?

Próbuję stworzyć demona w Pythonie. Znalazłem następujące pytanie , które zawiera dobre zasoby, które obecnie śledzę, ale jestem ciekaw, dlaczego potrzebny jest podwójny widelec. Przeszukałem google i znalazłem wiele zasobów stwierdzających, że jest to konieczne, ale nie dlaczego.

Niektórzy wspominają, że ma to na celu uniemożliwić demonowi uzyskanie kontrolującego terminala. Jak by to zrobił bez drugiego widelca? Jakie są konsekwencje?

Patrząc na kod, do którego odwołuje się pytanie, uzasadnienie jest następujące:

Rozwidlić drugie dziecko i natychmiast wyjść, aby zapobiec zombie. Powoduje to osierocenie drugiego procesu potomnego, co powoduje, że proces init jest odpowiedzialny za jego czyszczenie. A ponieważ pierwsze dziecko jest liderem sesji bez terminala sterującego, możliwe jest, że może go zdobyć otwierając w przyszłości terminal (systemy oparte na Systemie V). Ten drugi rozwidlenie gwarantuje, że dziecko nie jest już liderem sesji, uniemożliwiając demonowi uzyskanie kontrolującego terminala.

Tak więc ma to na celu zapewnienie, że demon zostanie ponownie przeniesiony na init (na wypadek gdyby proces uruchamiający demona trwał długo) i eliminuje wszelkie szanse na to, że demon odzyska kontrolujący terminal tty. Więc jeśli żaden z tych przypadków nie ma zastosowania, jeden widelec powinien wystarczyć. „ Programowanie sieciowe w systemie Unix - Stevens ” ma dobrą sekcję na ten temat.

Próbowałem zrozumieć podwójny widelec i natknąłem się tutaj na to pytanie. Po wielu badaniach doszedłem do tego. Mamy nadzieję, że pomoże to lepiej wyjaśnić sprawę każdemu, kto ma takie samo pytanie.

W Uniksie każdy proces należy do grupy, która z kolei należy do sesji. Oto hierarchia…

Sesja (SID) → Grupa procesów (PGID) → Proces (PID)

Pierwszy proces w grupie procesów staje się liderem grupy procesów, a pierwszy proces w sesji zostaje liderem sesji. Z każdą sesją może być powiązany jeden TTY. Tylko lider sesji może przejąć kontrolę nad TTY. Aby proces był naprawdę zdemonizowany (działał w tle), powinniśmy upewnić się, że lider sesji został zabity, aby sesja nie mogła kiedykolwiek przejąć kontroli nad TTY.

Uruchomiłem przykładowy demon Pythona Sandera Marechala z tej witryny na moim Ubuntu. Oto wyniki z moimi komentarzami.

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046
2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046
3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085
4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

Zauważ, że proces jest liderem sesji po Decouple#1, ponieważ tak jest PID = SID. Nadal może przejąć kontrolę nad TTY.

Zauważ, że Fork#2nie jest już liderem sesji PID != SID. Ten proces nigdy nie może przejąć kontroli nad TTY. Naprawdę zdemonizowany.

Osobiście uważam, że podwójna terminologia jest myląca. Lepszym idiomem może być fork-decouple-fork.

Dodatkowe interesujące linki:

• Procesy Unix - http://www.win.tue.nl/~aeb/linux/lk/lk-10.html

Ściśle mówiąc, double-fork nie ma nic wspólnego z wychowywaniem demona jako dziecka init. Wszystko, co jest potrzebne do ponownego wychowania dziecka, to to, że rodzic musi wyjść. Można to zrobić za pomocą tylko jednego widelca. Również samo wykonanie podwójnego rozwidlenia nie powoduje ponownego zrobienia procesu demona init; rodzic demona musi wyjść. Innymi słowy, rodzic zawsze kończy pracę podczas rozwidlania odpowiedniego demona, aby proces demona był ponownie rodzicielski init.

Dlaczego więc podwójny widelec? POSIX.1-2008 Sekcja 11.1.3, " Terminal sterujący ", zawiera odpowiedź (podkreślenie dodane):

Terminal sterujący sesją jest przydzielany przez lidera sesji w sposób określony w implementacji. Jeśli lider sesji nie ma terminala sterującego i otwiera plik urządzenia terminala, który nie jest już skojarzony z sesją bez użycia O_NOCTTYopcji (zobacz open()), definiowane jest w implementacji, czy terminal stanie się terminalem sterującym lidera sesji. Jeśli proces, który nie jest liderem sesji, otwiera plik terminala, lub O_NOCTTYopcja jest używana na open(), to terminal ten nie powinien stać się terminalem kontrolującym proces wywołujący .

To mówi nam, że jeśli proces demona robi coś takiego ...

int fd = open("/dev/console", O_RDWR);

... wtedy proces demona może zostać przyjęty /dev/consolejako terminal sterujący, w zależności od tego, czy proces demona jest liderem sesji oraz w zależności od implementacji systemu. Program może zagwarantować, że powyższe wywołanie nie uzyska terminala sterującego, jeśli program najpierw upewni się, że nie jest on liderem sesji.

Normalnie, podczas uruchamiania demona, setsidjest wywoływana (z procesu potomnego po wywołaniu fork) w celu odłączenia demona od jego kontrolującego terminala. Jednak wywołanie setsidoznacza również, że proces wywołujący będzie liderem sesji nowej sesji, co pozostawia otwartą możliwość, że demon mógłby ponownie uzyskać kontrolujący terminal. Technika podwójnego rozwidlenia zapewnia, że ​​proces demona nie jest liderem sesji, co gwarantuje, że wywołanie open, jak w powyższym przykładzie, nie spowoduje, że proces demona ponownie przejmie kontrolujący terminal.

Technika podwójnego widelca jest nieco paranoiczna. Może to nie być konieczne, jeśli wiesz, że demon nigdy nie otworzy pliku urządzenia terminala. Ponadto w niektórych systemach może nie być konieczne, nawet jeśli demon otwiera plik urządzenia terminala, ponieważ to zachowanie jest zdefiniowane w implementacji. Jednak jedną rzeczą, która nie jest zdefiniowana w ramach implementacji, jest to, że tylko lider sesji może przydzielić terminal sterujący. Jeśli proces nie jest liderem sesji, nie może przydzielić kontrolującego terminala. Dlatego, jeśli chcesz być paranoikiem i być pewnym, że proces demona nie może przypadkowo uzyskać kontrolującego terminala, niezależnie od jakichkolwiek specyfikacji zdefiniowanych w implementacji, niezbędna jest technika podwójnego rozwidlenia.

Zaczerpnięte z Bad CTK :

„W niektórych odmianach Uniksa jesteś zmuszony do wykonania podwójnego rozwidlenia podczas uruchamiania, aby przejść do trybu demona. Dzieje się tak, ponieważ pojedyncze rozwidlenie nie jest gwarantowane do odłączenia się od kontrolującego terminala.”

Według „Advanced Programming in the Unix Environment” Stephens and Rago, drugi fork jest raczej zaleceniem i ma na celu zagwarantowanie, że demon nie uzyska kontrolującego terminala w systemach opartych na Systemie V.

Jednym z powodów jest to, że proces nadrzędny może natychmiast wait_pid () dla dziecka, a następnie zapomnieć o tym. Kiedy wnuk umiera, jego rodzic jest inicjowany i będzie czekał () na to - i wyprowadzi go ze stanu zombie.

W rezultacie proces nadrzędny nie musi być świadomy rozwidlonych elementów potomnych, a także umożliwia rozwidlenie długo działających procesów z bibliotek itp.

Wywołanie daemon () ma wywołanie nadrzędne _exit (), jeśli się powiedzie. Pierwotną motywacją mogło być pozwolenie rodzicowi na wykonanie dodatkowej pracy, podczas gdy dziecko demonizuje.

Może również opierać się na błędnym przekonaniu, że jest to konieczne, aby upewnić się, że demon nie ma procesu nadrzędnego i jest ponownie inicjowany - ale tak się stanie, gdy rodzic umrze w przypadku pojedynczego rozwidlenia.

Przypuszczam więc, że w końcu wszystko sprowadza się do tradycji - pojedynczy widelec wystarczy, o ile i tak rodzic umiera w krótkim czasie.

Wydaje się, że porządna dyskusja na ten temat znajduje się pod adresem http://www.developerweb.net/forum/showthread.php?t=3025

Cytując mlampkin stamtąd:

... pomyśl o wywołaniu setsid () jako o "nowym" sposobie robienia rzeczy (odłączenie się od terminala), a [drugie] wywołanie fork () po nim jako o redundancji do obsługi SVr4 ...

W ten sposób może być łatwiejsze do zrozumienia:

• Pierwszy fork i setsid utworzą nową sesję (ale identyfikator procesu == identyfikator sesji).
• Drugi rozwidlenie zapewnia, że ​​identyfikator procesu! = Identyfikator sesji.