Edycja na 2016:
Te pytania i odpowiedzi poprzedzają awarię systemd v230 . Począwszy od wersji systemd v230, nową domyślną funkcją jest zabijanie wszystkich dzieci kończącej sesji logowania, niezależnie od tego, jakie historycznie ważne środki ostrożności zostały podjęte, aby temu zapobiec. Zachowanie może zostać zmieniona poprzez ustawienie KillUserProcesses=now /etc/systemd/logind.conflub obejść przy użyciu mechanizmów Systemd specyficznych dla uruchamiania demona w przestrzeni użytkownika. Mechanizmy te są poza zakresem tego pytania.
Poniższy tekst opisuje, jak rzeczy tradycyjnie działały w przestrzeni projektowej UNIX dłużej niż Linux.
Zostaną zabici, ale niekoniecznie natychmiast. Zależy to od tego, ile czasu zajmuje demonowi SSH podjęcie decyzji o zerwaniu połączenia. Poniżej znajduje się dłuższe wyjaśnienie, które pomoże ci zrozumieć, jak to naprawdę działa.
Po zalogowaniu demon SSH przydzielił ci pseudo-terminal i podłączył go do skonfigurowanej powłoki logowania użytkownika. Nazywa się to terminalem sterującym. Każdy program, który uruchomisz normalnie w tym momencie, bez względu na głębokość warstw powłok, ostatecznie prześledzi swoje pochodzenie z powrotem do tej powłoki. Możesz to zaobserwować za pomocą pstreepolecenia.
Gdy proces demona SSH skojarzony z twoim połączeniem zdecyduje, że twoje połączenie jest martwe, wysyła sygnał rozłączenia ( SIGHUP) do powłoki logowania. To powiadamia powłokę, że zniknąłeś i że powinna zacząć się po niej porządkować. To, co dzieje się w tym momencie, jest specyficzne dla powłoki (wyszukaj na stronie dokumentacji „HUP”), ale w przeważającej części zacznie on wysyłać SIGHUPdo uruchomionych zadań z nim związanych przed zakończeniem. Każdy z tych procesów z kolei zrobi wszystko, co jest skonfigurowany po otrzymaniu tego sygnału. Zwykle oznacza to zakończenie. Jeśli te zadania mają swoje własne, sygnał również często zostanie przekazany.
Procesy, które przetrwają zawieszenie terminalu sterującego, to te, które albo oddzieliły się od posiadania terminalu (procesy demona, które uruchomiłeś w nim), albo te, które zostały wywołane z prefiksem nohup. (tzn. „nie rozłączaj się”) Demony inaczej interpretują sygnał HUP; ponieważ nie mają terminala sterującego i nie odbierają automatycznie sygnału HUP, zamiast tego jest on ponownie traktowany jako ręczne żądanie administratora o ponowne załadowanie konfiguracji. Jak na ironię oznacza to, że większość administratorów nie uczy się używania „zawieszenia” tego sygnału dla nie-demonów dopiero dużo, dużo później. Dlatego to czytasz!
Multipleksery terminali są powszechnym sposobem utrzymywania środowiska powłoki w stanie nienaruszonym między rozłączeniami. Pozwalają one odłączyć się od procesów powłoki w sposób, który można do nich ponownie podłączyć później, niezależnie od tego, czy to rozłączenie było przypadkowe czy celowe. tmuxi screensą bardziej popularne; składnia na ich użycie jest poza zakresem twojego pytania, ale warto je przeanalizować.
Poproszono mnie o wyjaśnienie, ile czasu zajmuje demonowi SSH podjęcie decyzji o zerwaniu połączenia. Jest to zachowanie specyficzne dla każdej implementacji demona SSH, ale możesz liczyć, że wszystkie z nich zakończą się, gdy którakolwiek ze stron zresetuje połączenie TCP. Stanie się to szybko, jeśli serwer spróbuje zapisać do gniazda, a pakiety TCP nie zostaną potwierdzone, lub powoli, jeśli nic nie będzie próbowało zapisać do PTY.
W tym szczególnym kontekście czynniki, które najprawdopodobniej wywołują zapis, to:
- Proces (zwykle ten na pierwszym planie), który próbuje zapisać na PTY po stronie serwera. (serwer-> klient)
- Użytkownik próbuje napisać do PTY po stronie klienta. (klient-> serwer)
- Dowolne środki utrzymania. Zazwyczaj nie są one domyślnie włączone ani przez klienta, ani przez serwer, i zazwyczaj występują dwa warianty: poziom aplikacji i protokół TCP (tj
SO_KEEPALIVE.). Keepalives to zarówno serwer, jak i klient, rzadko wysyłające pakiety na drugą stronę, nawet jeśli nic nie miałoby powodu pisać w gnieździe. Chociaż zwykle ma to na celu ominięcie zapór ogniowych zbyt szybko przerywających połączenia, ma dodatkowy efekt uboczny, powodując, że nadawca zauważa, kiedy druga strona nie reaguje tak szybko.
Obowiązują tutaj zwykłe reguły dla sesji TCP: jeśli nastąpi przerwa w łączności między klientem a serwerem, ale żadna ze stron nie spróbuje wysłać pakietu podczas problemu, połączenie przetrwa, pod warunkiem, że obie strony będą wtedy reagować i otrzymają oczekiwany TCP numery sekwencyjne.
Jeśli jedna ze stron zdecyduje, że gniazdo jest martwe, efekty są zwykle natychmiastowe: proces sshd wyśle HUPi sam się zakończy (jak opisano wcześniej) lub klient powiadomi użytkownika o wykrytym problemie. Warto zauważyć, że tylko dlatego, że jedna strona uważa, że druga nie żyje, nie oznacza, że druga została o tym powiadomiona. Osierocona strona połączenia zwykle pozostaje otwarta, dopóki nie spróbuje do niej napisać i przekroczy limit czasu lub nie otrzyma resetu TCP z drugiej strony. (jeśli łączność była wówczas dostępna) Czyszczenie opisane w tej odpowiedzi następuje tylko wtedy, gdy serwer zauważy.
screen, spróbuj powtórzyć .