Řešení 1:
Úpravy pro rok 2016:
Tyto otázky a odpovědi předcházejí debaklu systemd v230. Od systemd v230 je novým výchozím nastavením zabít všechny potomky ukončující relace přihlášení, bez ohledu na to, jaká historicky platná opatření byla přijata, aby se tomu zabránilo. Chování lze změnit nastavením KillUserProcesses=no v /etc/systemd/logind.conf nebo obcházeno pomocí mechanismů specifických pro systemd pro spuštění démona v uživatelském prostoru. Tyto mechanismy jsou mimo rozsah této otázky.
Níže uvedený text popisuje, jak věci tradičně fungovaly v návrhovém prostoru UNIX déle, než existoval Linux.
Budou zabiti, ale ne nutně okamžitě. Záleží na tom, jak dlouho trvá, než démon SSH rozhodne, že vaše připojení je mrtvé. Následuje delší vysvětlení, které vám pomůže pochopit, jak to vlastně funguje.
Když jste se přihlásili, démon SSH vám přidělil pseudoterminál a připojil jej k nakonfigurovanému přihlašovacímu shellu vašeho uživatele. Toto se nazývá řídicí terminál. Každý program, který v tomto bodě normálně spustíte, bez ohledu na to, kolik vrstev skořápek je hluboký, nakonec vystopuje své předky zpět k této skořápce. Můžete to pozorovat pomocí pstree příkaz.
Když proces démona SSH spojený s vaším připojením rozhodne, že vaše připojení je mrtvé, vyšle signál zavěšení (SIGHUP ) do přihlašovacího shellu. To upozorní shell, že jste zmizeli a že by po sobě měl začít uklízet. To, co se stane v tomto okamžiku, je specifické pro shell (vyhledejte na jeho dokumentační stránce "HUP"), ale většinou začne odesílat SIGHUP na spuštěné úlohy s ním spojené před ukončením. Každý z těchto procesů zase udělá vše, k čemu je nakonfigurován, po přijetí tohoto signálu. Obvykle to znamená ukončení. Pokud mají tyto práce vlastní úkoly, signál bude často předán také.
Procesy, které přežijí zavěšení řídicího terminálu, jsou ty, které se buď oddělily od terminálu (procesy démona, které jste v něm spustili), nebo ty, které byly vyvolány s předponou nohup příkaz. (tj. "nezavěšujte na toto") Démoni interpretují signál HUP odlišně; protože nemají řídicí terminál a automaticky nepřijímají signál HUP, je místo toho znovu použit jako manuální požadavek správce na opětovné načtení konfigurace. Ironicky to znamená, že většina adminů se naučí "zavěšení" použití tohoto signálu pro non-démony až mnohem, mnohem později. Proto to čtete!
Terminálové multiplexory jsou běžným způsobem, jak udržet prostředí prostředí mezi odpojeními nedotčené. Umožňují vám odpojit se od vašich procesů shellu způsobem, že se k nim můžete později znovu připojit, bez ohledu na to, zda toto odpojení bylo náhodné nebo záměrné. tmux a screen jsou populárnější; syntaxe pro jejich použití přesahuje rozsah vaší otázky, ale stojí za to se na ně podívat.
Bylo požadováno, abych vysvětlil, jak dlouho trvá, než démon SSH rozhodne, že vaše připojení je mrtvé. Toto je chování, které je specifické pro každou implementaci démona SSH, ale můžete se spolehnout, že se všechny ukončí, když kterákoli strana resetuje připojení TCP. To se stane rychle, pokud se server pokusí zapisovat do soketu a TCP pakety nejsou potvrzeny, nebo pomalu, pokud se nic nepokouší zapisovat do PTY.
V tomto konkrétním kontextu faktory s největší pravděpodobností spouštějí zápis:
- Proces (obvykle ten v popředí), který se pokouší zapisovat do PTY na straně serveru. (server->klient)
- Uživatel, který se pokouší zapisovat do PTY na straně klienta. (klient->server)
- Keepalivy jakéhokoli druhu. Obvykle nejsou ve výchozím nastavení povoleny ani klientem, ani serverem a obvykle existují dvě varianty:aplikační úroveň a TCP (tj.
SO_KEEPALIVE). Keepalives znamená, že buď server nebo klient zřídka posílají pakety na druhou stranu, i když by jinak nic nemělo důvod zapisovat do soketu. I když je to obvykle zamýšleno k obejití firewallů, které příliš rychle uplynou časový limit pro připojení, má to další vedlejší účinek, protože odesílatel si všimne, že druhá strana nereaguje mnohem rychleji.
Zde platí obvyklá pravidla pro TCP relace:pokud dojde k přerušení konektivity mezi klientem a serverem, ale žádná strana se během problému nepokusí odeslat paket, spojení přežije za předpokladu, že obě strany poté reagují a přijímají očekávaný TCP pořadová čísla.
Pokud jedna strana rozhodne, že socket je mrtvý, účinky jsou obvykle okamžité:proces sshd odešle HUP a samočinně se ukončí (jak bylo popsáno výše), nebo klient upozorní uživatele na zjištěný problém. Stojí za zmínku, že to, že si jedna strana myslí, že ta druhá je mrtvá, neznamená, že ta druhá o tom byla informována. Osiřelá strana připojení obvykle zůstane otevřená, dokud se na ni nepokusí zapsat a nevyprší časový limit, nebo neobdrží reset TCP z druhé strany. (pokud bylo připojení v danou chvíli k dispozici) Vyčištění popsané v této odpovědi proběhne pouze po serveru si všiml.
Řešení 2:
Jak již uvedli jiní, jakmile se odpojíte od ssh, vše, co v něm běží, je pryč.
Jak uvedl @Michael Hampton a další, můžete použít nástroje jako tmux nebo screen odpojit/znovu připojit k terminálům bez ztráty jejich obsahu (tj. podřízených procesů).
Navíc můžete proces umístit na pozadí pomocí ampersandu & a poté použijte příkaz disown oddělit je od aktuálního shellu.
# start a command
% sleep 5000 &
[1] 3820
# check it
% jobs
[1]+ Running sleep 5000 &
# disown everything
% disown -a
# check it again (gone from shell)
% jobs
%
# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml 3820 23791 0 00:16 pts/1 00:00:00 sleep 5000
%
Řešení 3:
Ne, všechny programy jsou stále připojeny k terminálu a nejsou umístěny na pozadí s něčím jako nohup , by byl zabit.
To je důvod, proč existují virtuální terminálová řešení jako tmux a starší screen které vytvářejí relace, které pokračují v běhu, i když jste odpojeni, a ke kterým se můžete později znovu připojit.