Có cách nào để ngăn chặn tmux đóng băng khi nhiều văn bản được xuất ra thiết bị đầu cuối không?

Trong phiên tmux bên trong xterm khi một chương trình tạo ra nhiều thông số (như cat very_long_filetoàn bộ phiên bị đóng băng trong một thời gian. Ngay cả khi tôi nhấn Ctrl-C, không có gì bị gián đoạn. Có lẽ vì tmux bị đóng băng và nó không chuyển tiếp Ctrl-C chương trình tạo đầu ra. Có cách nào để ngăn chặn điều này.

Giải pháp chính xác là xem xét các tùy chọn c0- * cho tmux để thử và giới hạn tốc độ đầu ra. Lý do vấn đề này tồn tại là do dữ liệu được gửi đến thiết bị đầu cuối nhanh hơn nó có thể hiển thị nó, vì vậy giới hạn tốc độ là cách duy nhất.

Tôi vẫn gặp sự cố này trong tmux 1.6-2 trên Ubuntu 12.10. Một cách giải quyết khác mà tôi đã tìm thấy là tách khỏi phiên (tiền tố + d) và sau đó reattach ( tmux attach, ứng cử viên tốt cho bí danh hệ vỏ nhanh). Có vẻ như tmux thực sự phản hồi dưới mui xe --- bạn có thể xác nhận rằng quy trình của bạn thực sự bị giết ngay lập tức với ctrl-c --- đó chỉ là bản vẽ bị chặn. Detatch hoạt động ngay lập tức và khi bạn gắn lại, bản vẽ sẽ bị bỏ qua đến cuối.

Theo tôi biết không có cách nào để ngăn chặn nó trong các bản phát hành hiện tại nhưng một số công việc đang diễn ra. Bạn có thể tìm thấy một số bản vá trong danh sách gửi thư của tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Một từ khóa tốt để tìm kiếm trên web là "kiểm soát dòng chảy".

Thật không may, các tùy chọn c0- * cho giới hạn tốc độ đã bị xóa kể từ phiên bản tmux 2.1 ( changelog ). Theo tôi biết, cách duy nhất để tùy chỉnh giới hạn tốc độ là cập nhật các biến ảnh hưởng đến nó trong mã nguồn (tmux.h):

" READ_SIZE là kích thước tối đa của dữ liệu để giữ từ một pty (hình mờ cao của sự kiện). READ_BACKOFF là lượng dữ liệu đang chờ để được xuất ra một tty trước khi đọc pty sẽ bị tắt. READ_TIME là thời gian lùi lại trước khi lần đọc tiếp theo (tính bằng micro giây) nếu một tty ở trên READ_BACKOFF. "

Nơi bạn sẽ tìm thấy mặc định: (kể từ tmux v2.2):

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100

Câu trả lời https://superuser.com/a/589896/311481 hoạt động tốt. Tôi sử dụng các giá trị sau:

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

Một mẹo khác: nếu bạn sử dụng ssh trong tmux, thay vào đó hãy sử dụng mosh: http://mosh.mit.edu/ Nó hoạt động thông minh hơn như hiển thị đầu ra của chương trình. Nó cố gắng hiển thị trạng thái màn hình cuối cùng thả trung gian khi thích hợp. Vì vậy, tmux sẽ không bao giờ đóng băng nếu nhiều đầu ra được tạo ra trong các khung của nó với các phiên mosh bên trong.

Không giống như SSH, giao thức dựa trên UDP của mosh xử lý mất gói một cách duyên dáng và đặt tốc độ khung hình dựa trên các điều kiện mạng. Mosh không lấp đầy bộ đệm mạng, vì vậy Control-C luôn hoạt động để ngăn chặn quá trình chạy trốn.

Vì SSP [Giao thức đồng bộ hóa trạng thái mà mosh sử dụng] hoạt động ở lớp đối tượng và có thể kiểm soát tốc độ đồng bộ hóa (nói cách khác là tốc độ khung hình), nên không cần gửi mỗi byte mà nó nhận được từ ứng dụng. Điều đó có nghĩa là Mosh có thể điều chỉnh các khung để không lấp đầy bộ đệm mạng, duy trì khả năng phản hồi của kết nối và đảm bảo Control-C luôn hoạt động nhanh. Các giao thức phải gửi mỗi byte không thể làm điều này.

Hãy thử trình giả lập thiết bị đầu cuối khác nhau. Trên RedHat 6.5, konsole (KDE) không có vấn đề đóng băng (tmux 2.3 và master); tuy nhiên, cả xterm và gnome-terminal đều bị đóng băng.