답변:
이 Q & A는 systemd v230 debacle 보다 우선합니다 . systemd v230부터 새로운 기본값은이를 방지하기 위해 역사적으로 유효한 예방 조치에 관계없이 종료 로그인 세션의 모든 하위 항목을 종료하는 것입니다. 동작은 KillUserProcesses=no
에서 설정 하여 변경 /etc/systemd/logind.conf
하거나 사용자 공간에서 데몬을 시작하기위한 systemd 특정 메커니즘을 사용하여 회피 할 수 있습니다 . 이러한 메커니즘은이 질문의 범위를 벗어납니다.
아래의 텍스트는 Linux보다 오랫동안 UNIX 디자인 공간에서 전통적으로 작동 한 방식을 설명합니다.
그들은 죽을 것이지만 반드시 즉각적인 것은 아닙니다. SSH 데몬이 연결이 끊어 졌다고 결정하는 데 걸리는 시간에 따라 다릅니다. 다음은 실제로 어떻게 작동하는지 이해하는 데 도움이되는 더 긴 설명입니다.
로그인하면 SSH 데몬이 의사 터미널을 할당하여 사용자의 구성된 로그인 쉘에 연결했습니다. 이것을 제어 터미널이라고합니다. 얼마나 많은 쉘 층이 있더라도 그 시점에서 정상적으로 시작하는 모든 프로그램은 궁극적으로 그 조상을 그 쉘로 추적합니다. pstree
명령으로 이를 확인할 수 있습니다 .
연결과 관련된 SSH 데몬 프로세스가 연결이 끊어 졌다고 SIGHUP
판단하면 로그인 셸에 끊기 신호 ( )를 보냅니다 . 이렇게하면 쉘이 사라졌으며 자체적으로 정리를 시작해야 함을 알립니다. 이 시점에서 발생하는 일은 쉘에 따라 다르지만 ( "HUP"에 대한 문서 페이지를 검색하십시오), 대부분 SIGHUP
종료하기 전에 연관된 작업을 보내기 시작 합니다. 이러한 각 프로세스는 차례로 해당 신호를 수신하도록 구성된 모든 작업을 수행합니다. 일반적으로 이는 종료를 의미합니다. 해당 작업에 자체 작업이있는 경우 신호도 종종 전달됩니다.
제어 터미널의 정지에서 살아남은 프로세스는 터미널을 갖지 못하게하는 프로세스 (터미널 내부에서 시작한 데몬 프로세스) 또는 접두사가 붙은 nohup
명령 으로 호출 된 프로세스입니다 . 데몬은 HUP 신호를 다르게 해석합니다. 제어 터미널이없고 HUP 신호를 자동으로 수신하지 않기 때문에 대신 관리자의 구성을 다시로드하라는 수동 요청으로 사용됩니다. 아이러니하게도 이것은 대부분의 관리자가 비 데몬이 아닌 경우에이 신호의 "중단"사용법을 훨씬 나중에 배우지 않음을 의미합니다. 이것이 당신이 이것을 읽는 이유입니다!
터미널 멀티플렉서는 연결 끊기 사이에 쉘 환경을 손상시키지 않는 일반적인 방법입니다. 연결 해제가 우발적이든 의도적이든 상관없이 나중에 다시 연결할 수있는 방식으로 쉘 프로세스에서 분리 할 수 있습니다. tmux
그리고 screen
더 인기있는 것들입니다; 그것들을 사용하는 구문은 귀하의 질문의 범위를 벗어나지 만 조사해 볼 가치가 있습니다.
SSH 데몬이 연결이 끊어 졌다고 결정하는 데 걸리는 시간에 대해 자세히 설명했습니다. 이것은 SSH 데몬의 모든 구현에 고유 한 동작이지만 어느 쪽이 TCP 연결을 재설정 할 때 종료되도록 모든 것을 사용할 수 있습니다. 서버가 소켓에 쓰려고 시도하고 TCP 패킷이 확인되지 않으면 PTY에 쓰려고하지 않으면 느리게 발생합니다.
이 특정 상황에서 쓰기를 트리거 할 가능성이 가장 높은 요소는 다음과 같습니다.
SO_KEEPALIVE
. Keepalives는 다른 방법으로 소켓에 쓸 이유가없는 경우에도 서버 나 클라이언트가 다른쪽으로 패킷을 보내는 경우가 적습니다. 이는 일반적으로 연결 시간이 너무 빨리 초과되는 방화벽을 차단하기위한 것이지만 상대방이 훨씬 빨리 응답하지 않으면 발신자에게 알리는 부작용이 있습니다.TCP 세션에 대한 일반적인 규칙이 여기에 적용됩니다. 클라이언트와 서버 사이의 연결이 중단되었지만 문제가 발생하는 동안 어느 쪽도 패킷을 보내려고 시도하지 않으면 양쪽이 나중에 응답하고 예상되는 TCP를 수신하면 연결이 유지됩니다. 시퀀스 번호.
한쪽이 소켓이 작동하지 않는다고 결정한 경우, 그 영향은 일반적으로 즉각적입니다. sshd 프로세스가 전송 HUP
및 자체 종료 (앞서 설명한대로)하거나 클라이언트가 사용자에게 감지 된 문제점을 통지합니다. 한 쪽이 다른 쪽이 죽었다고 생각한다고해서 다른 쪽이이를 통보 받았다는 것을 의미하지는 않습니다. 연결의 연결이 끊긴 쪽은 일반적으로 연결을 시도하고 시간이 초과되거나 다른 쪽에서 TCP 재설정을받을 때까지 열린 상태로 유지됩니다. (당시 연결을 사용할 수있는 경우)이 답변에 설명 된 정리는 서버 가 확인한 후에 만 수행됩니다 .
dtach
url은 여기 있습니다 : dtach.sourceforge.net
kill -HUP
누군가의 터미널을 강제로 끊기 위해 루트로 사용할 수 있습니다 . 정당한 이유없이이 작업을 수행해서는 안됩니다. 유지 관리 중에 사용자가 셸을 실행중인 상태로두면 마일리지가 거의 없어지고 해당 셸이 계속 열려있는 파일 시스템을 마운트 해제해야합니다. 사용자가 연결되었지만 터미널 유휴 상태 인 경우 신호를 sshd 프로세스로 보냅니다. 그렇지 않으면, 터미널 멀티플렉서 내부에서 실행중인 경우 중지하려는 쉘로 보내십시오. 껍질을 끊어 작업을 방해하십시오!
다른 사람들이 언급했듯이 ssh에서 연결을 끊으면 내부에서 실행중인 모든 것이 사라집니다.
으로 @Michael 햄튼 다른 사람들이 당신과 같은 도구를 사용할 수 있습니다 언급 한 tmux
또는 screen
분리 / 그 내용 (즉, 자식 프로세스)를 잃지 않고 단자에 연결합니다.
또한 앰퍼샌드 &
를 사용 하여 프로세스를 백그라운드에 넣고 명령 disown
을 사용 하여 프로세스를 현재 쉘과 분리 할 수 있습니다.
# 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
%
disown
ed 프로세스 에 다시 첨부 할 수 있습니까?
screen
시도 하십시오 .