프로그램이 많은 출력을 생성 할 때 xterm 내부의 tmux 세션에서 (한동안 cat very_long_file전체 세션 과 같이 잠시 동안. Ctrl-C를 눌러도 아무것도 중단되지 않습니다. tmux가 정지되어 Ctrl-C를 전달하지 않기 때문에 아마도 프로그램이 출력을 생성하는 것을 막을 방법이 있습니까?
답변
올바른 해결책은 c0- * 옵션을 tmux로보고 출력을 평가하고 제한하는 것입니다. 이 문제가 존재하는 이유는 데이터를 표시 할 수있는 것보다 빠르게 터미널로 데이터를 전송하기 때문입니다. 따라서 속도 제한이 유일한 방법입니다.
답변
우분투 12.10의 tmux 1.6-2에서 여전히이 문제가 있습니다. 내가 찾은 한 가지 해결 방법은 세션 (접두사 + D)에서 달린 것을 빼낸 다음 다시 연결하는 것입니다 ( tmux attach빠른 쉘 별명에 대한 좋은 후보). tmux가 실제로는 반응이 빠른 것처럼 보입니다. 프로세스가 실제로 ctrl-c로 즉시 종료되었음을 확인할 수 있습니다. 차단하는 도면 일뿐입니다. 분리는 즉시 작동하며 다시 부착하면 도면이 끝까지 건너 뜁니다.
답변
내가 아는 한 현재 릴리스에서는이를 방지 할 방법이 없지만 일부 작업이 진행 중입니다. tmux의 메일 링리스트 http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 에서 일부 패치를 찾을 수 있습니다 .
웹을 검색하기에 좋은 키워드는 “흐름 제어”입니다.
답변
불행히도 속도 제한에 대한 c0- * 옵션은 tmux 버전 2.1 ( changelog ) 에서 제거되었습니다 . 내가 아는 한, 속도 제한을 사용자 정의하는 유일한 방법은 소스 코드 (tmux.h)에서 변수에 영향을 미치는 변수를 업데이트하는 것입니다.
” READ_SIZE는 pty (이벤트 상위 워터 마크)에서 보유 할 최대 데이터 크기입니다. READ_BACKOFF는 pty 읽기가 백업되기 전에 tty로 출력되기를 기다리는 데이터의 양입니다. READ_TIME은 tty가 READ_BACKOFF보다 높으면 다음 읽기 (마이크로 초)입니다. “
기본값을 찾을 수있는 위치 : (tmux v2.2 기준) :
#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100
답변
답변 https://superuser.com/a/589896/311481 이 잘 작동합니다. 다음 값을 사용합니다.
setw -g c0-change-trigger 10
setw -g c0-change-interval 250
또 다른 팁 : tmux 내에서 ssh를 사용하는 경우 대신 mosh를 사용하십시오. http://mosh.mit.edu/ 프로그램의 출력을 표시하는 것이 더 똑똑합니다. 적절한 경우 마지막 화면 상태 드롭 중간체를 표시하려고 시도합니다. 따라서 mosh 세션이있는 창에서 많은 출력이 생성되면 tmux가 멈추지 않습니다.
SSH와 달리 mosh의 UDP 기반 프로토콜은 패킷 손실을 정상적으로 처리하고 네트워크 조건에 따라 프레임 속도를 설정합니다. Mosh는 네트워크 버퍼를 채우지 않으므로 Control-C는 항상 런 어웨이 프로세스를 중단합니다.
SSP (mosh가 사용하는 State Synchronization Protocol)는 객체 계층에서 작동하고 동기화 속도 (즉, 프레임 속도)를 제어 할 수 있기 때문에 응용 프로그램에서 수신하는 모든 바이트를 보낼 필요는 없습니다. 즉, Mosh는 네트워크 버퍼를 채우지 않도록 프레임을 조절하여 연결 응답 성을 유지하고 Control-C가 항상 빠르게 작동하도록 할 수 있습니다. 모든 바이트를 보내야하는 프로토콜은이 작업을 수행 할 수 없습니다.
답변
다른 터미널 에뮬레이터를 사용해보십시오. RedHat 6.5에서 곤솔 (KDE)에는 동결 문제가 없습니다 (tmux 2.3 및 마스터). 그러나 xterm과 gnome-terminal은 모두 얼어 붙습니다.