SSH에서 vim이 멈추나요? VPN을 탓하기 전에 stty를 확인하세요

이런 세션은 편집기가 시작되는 동안 연결을 유지하다가, SSH 프로세스가 분명히 살아 있는데도 화면 갱신을 멈춥니다. 입력해도 아무것도 나오지 않고, Ctrl-C도 아무것도 하지 않는 것처럼 보이며, 뻔한 결론은 VPN이 무언가를 떨어뜨렸다는 것입니다. 대부분의 경우 터널은 멀쩡하고 원격 의사 터미널이 아무도 의도하지 않은 상태에 있는데, 에코, 정규 입력, 흐름 제어가 네트워크가 아니라 터미널 안에 살기 때문입니다. 그 셋 중 무엇이 움직였는지 알아내는 것은 두 명령의 일입니다.

멈춤은 터널이 아니라 터미널 안에 산다

의사 터미널은 바이트보다 많은 것을 나릅니다. 라인 규율 플래그를 보관하며, 입력이 에코되는지, 읽기가 새 줄을 기다리는지, 특정 문자가 신호를 만드는지, 제어 문자로 출력을 멈출 수 있는지를 결정합니다. 대화형 편집기는 그 터미널을 조작하는 동안 내내 원시 모드로 바꾸고 종료할 때 이전 설정을 복원해야 합니다. 복원이 일어나지 않으면, 연결이 한 번도 끊기지 않았더라도 돌아온 셸은 떠난 셸이 아니게 됩니다.

무엇이든 결론 내리기 전에 터미널을 비교하세요. 같은 편집기를 실행하는 두 번째 세션은 클라이언트와 경로가 일을 할 수 있음을 증명하지만 플래그가 깨진 터미널에 대해서는 아무것도 말하지 않습니다.

멈춘 터미널에서 설정을 읽으세요

먼저 장치를 식별하고, 그다음 그 상태의 두 가지 형식을 읽으세요. 읽을 수 있는 형식은 무엇이 설정되었는지 보여 주고, 기계 형식은 나중에 되돌려 넣을 수 있는 형식입니다.

tty
stty -a
stty -g

세 플래그 그룹이 이런 보고의 대부분을 설명합니다. 에코 설정은 키 입력이 아예 보이는지를 결정하므로, 에코가 꺼진 터미널은 셸이 모든 문자를 받고 있어도 죽은 것처럼 보입니다. 정규 모드는 프로그램이 입력을 한 번에 한 줄씩 보는지를 결정하므로, 정규 모드로 남겨진 터미널에서는 원시 모드 응용 프로그램이 Enter까지 키를 무시하는 것처럼 보입니다. 흐름 제어 설정은 터미널이 XON과 XOFF 문자를 따르는지를 결정하며, 그 그룹이 셋 중 가장 그럴듯한 가짜 멈춤을 만듭니다.

무엇이든 바꾸기 전에, 특히 세션이 누군가 의존하는 사용자 지정 키 바인딩을 지니고 있을 때는 출력을 기록하세요. 기계 형식이 가장 안전한 기록이지만, 구현에 따라 달라지며 그것을 만든 같은 종류의 시스템이 복원해야 한다는 단서가 붙습니다.

그 터미널을 고치세요, 입력 중인 세션이 아니라

표준 복구는 매뉴얼 페이지에 나열된 정상 프로필을 복원하며, 터미널 하나에만 영향을 줍니다. 편집기가 그 터미널에 아직 저장하지 않은 작업을 들고 있다면, 작업이 저장될 때까지 그대로 두세요.

다른 셸에서 멈춘 장치를 명시적으로 지정하여 작업 중인 터미널이 건드려지지 않게 하세요.

stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane

화면 표시가 깨진 빈 화면은 깨진 라인 규율과 별개의 문제이며, reset 프로그램은 터미널 초기화 시퀀스를 보내 처리합니다. 검사할 수 있는 설정을 바꾸므로 상태 복구를 먼저 시도하되, reset 시퀀스는 화면을 다시 쓸 뿐 어떻게 깨졌는지는 설명하지 않으므로 뒤로 미루세요.

그럴듯한 멈춤 뒤의 Ctrl-S 함정

소프트웨어 흐름 제어가 켜져 있고 일반 문자가 지정되어 있으면, Ctrl-S는 터미널에 출력 보내기를 멈추라고 하고 Ctrl-Q는 재개하라고 합니다. 세션은 그동안 계속 살아 있고, Ctrl-Q 한 번이면 복구가 끝나는 경우가 많으며, 어떤 로그에도 아무것도 나타나지 않기 때문에 이 멈춤이 그렇게 많은 에스컬레이션을 견디는 것입니다.

가정하지 말고 실제 설정을 검사하세요. 시작과 정지 문자는 다시 지정하거나 비활성화할 수 있으며, 흐름 제어가 꺼진 터미널은 둘 다에 반응하지 않습니다.

상태가 돌아오거나 SSH 자체가 막힐 때

반복되는 나쁜 상태는 시작 파일, 래퍼 스크립트, 잘못된 창을 재설정하는 멀티플렉서, 원시 모드를 쥔 채 죽는 응용 프로그램처럼 플래그를 복원하지 않고 바꾸는 무언가를 가리킵니다. 일괄 재설정은 원인을 숨기고 의도한 설정을 덮어쓸 수 있으므로 무조건 재설정하는 대신 상태를 보고하는 조건부 점검을 추가하세요.

일반 SSH 트래픽도 막히거나 복구가 아무것도 바꾸지 못하면, 터미널은 더 이상 용의자가 아닙니다.

ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com

큰 전송 중에만 나타나는 지연은 경로 MTU 문제를 시사하고, 단일 키 입력까지 삼키는 지연은 패킷 크기가 아니라 경로나 서버를 가리킵니다. 두 번째 세션에서 작동하는 편집기는 첫 터미널이 언젠가 정상이었다는 증거가 아니므로 터미널 증거를 네트워크 증거와 분리하세요.