tmux làm chậm quá trình gián đoạn với Ctrl-C


25

Nếu tôi chạy một lệnh có nhiều đầu ra trong tmux, nhưng quyết định hủy nó bằng Ctrl-C, sẽ có độ trễ 10-15 giây trước khi dừng. Tuy nhiên, nếu tôi làm điều tương tự bên ngoài tmux, nó sẽ dừng ngay lập tức. Tại sao điều này, và nó có thể sửa chữa?

Trong thực tế, vấn đề này xuất hiện khi tôi đang thực hiện grep -Rtrên một thư mục lớn và tìm kiếm của tôi không bị hạn chế đủ. Một cách giải quyết khác là đưa kết quả lên wctrước để đảm bảo đầu ra không quá dài, nhưng đó chỉ là một bước khác tôi muốn tránh.


Ghi chú:

  • Điều này có hành vi tương tự trong Gnome Terminal, uxterm, st và một thiết bị đầu cuối ảo đơn giản (ví dụ: ctrl-alt-f2), nhưng độ trễ ít hơn trong thiết bị đầu cuối ảo đơn giản.
  • Tôi không phải là người duy nhất: http://www.mail-archive.com/tmux-users@lists.sourceforge.net/msg01569.html
  • Độ trễ dài hơn nếu cửa sổ đầu cuối của tôi lớn hơn. Đối với một thiết bị đầu cuối toàn màn hình, phải mất khoảng 15 giây để dừng grep -R(không có đối số khác) trong một thư mục nhà lộn xộn. Đối với thiết bị đầu cuối 80 × 25 ký tự, nó dừng gần như ngay lập tức.

Tôi không nhận thấy bất kỳ sự khác biệt rõ rệt. Tôi đã thử grep -R "a" ~/(không ghi vào tệp) ... và yes | nl | cut -f1 | head -9999999 > ~/filesau đó cat ~/file.
Peter.O

@ Peter.O Chỉ cần nhập "có", sau đó nhấn Enter, tmux của bạn sẽ bị tiêu diệt.
solotim

Câu trả lời:


10

tmux hiện có các tùy chọn sau:

c0-change-interval interval
c0-change-trigger trigger

Bạn có thể đặt giá trị cho các giá trị này, điều này sẽ giúp ^ C và bạn bè dễ dàng nhập hơn. Xem man tmux:

Hai tùy chọn này cấu hình một hình thức giới hạn tỷ lệ đơn giản cho một khung. Nếu tmux thấy hơn kích hoạt chuỗi C0 rằng sửa đổi màn hình (ví dụ, kí tự xuống dòng, linefeeds hoặc backspaces) trong một phần nghìn giây, nó sẽ ngừng cập nhật các cửa sổ ngay lập tức và thay vào đó vẽ lại nó hoàn toàn tất cả các khoảng thời gian mili giây. Điều này giúp ngăn chặn đầu ra nhanh (chẳng hạn như có (1)) áp đảo thiết bị đầu cuối. Mặc định là một kích hoạt 250 và một khoảng 100. Một kích hoạt bằng 0 sẽ vô hiệu hóa giới hạn tốc độ.


Đây phải là giải pháp được chấp nhận, bởi vì nó hoạt động.
polym

2
Ví dụ setw -g c0-change-trigger 10 setw -g c0-change-interval 250>> ~ / .tmux.conf
DmitrySandalov

2
Tôi đã thử những thứ này trên tmux 2.3 và chúng không được công nhận. Nó trở nên hoàn toàn không sử dụng được khi các lệnh phun ra nhiều đầu ra.
ijt

1
Kể từ Tmux 2.1, các tùy chọn này không còn tồn tại theo raw.githubusercontent.com/tmux/tmux/2.6/CHANGES Các tùy chọn c0- * cho giới hạn tỷ lệ đã bị xóa. Thay vào đó, một cách tiếp cận backoff được sử dụng.
megar

7

Bạn luôn có thể phát kill-panelệnh từ trong phiên. Nếu văn bản đầu cuối trông giống như rác đổi tên cửa sổ và / hoặc phát hành resetnên sửa nó.


4

tmuxđang chèn chính giữa cattiến trình và thiết bị đầu cuối của bạn, nó cần đọc đầu ra từ cat, ghi nó vào thiết bị đầu cuối, đồng thời đọc đầu vào của bạn từ thiết bị đầu cuối (^ C) và gửi nó đến trình bao để làm gián đoạn chỉ huy. Tôi không chắc chính xác điều gì gây ra sự chậm trễ, nhưng đó là điều gì đó về cách tmuxbộ đệm I / O giữa bạn và vỏ chạy vào tmux.


3

Giả sử bạn đang sử dụng ssh qua kết nối có độ trễ thấp, bạn đã thử sử dụng mosh chưa? Trong số những thứ rất hay khác như dự đoán đầu vào cũng như ngắt kết nối còn tồn tại và thậm chí là thay đổi IP ở phía máy khách, nó cũng đặc biệt cải thiện thời gian phản ứng khi sử dụng Ctrl-C (bằng cách chỉ cập nhật nội dung thiết bị đầu cuối thay vì gửi toàn bộ luồng) .

Bạn có thể sử dụng tmuxtrong moshmà không có bất kỳ vấn đề.


Thật kỳ lạ, điều này xảy ra khi tôi làm việc tại địa phương. mosh trông khá gọn gàng, mặc dù.
Snowball

1

Tôi đã gặp vấn đề này với tmux 2.3. Tôi đã thử thiết lập các tùy chọn kích hoạt c0-thay đổi và c0-thay đổi kích hoạt như được mô tả ở trên nhưng chúng không còn khả dụng. Đây là thay đổi git với giải pháp đã thử mới: https://github.com/tmux/tmux/commit/3f4ee98162cd5bb7000f93fec0e631e123b1281d

Hoàn nguyên về tmux 1.8 đã khắc phục sự cố cho tôi mà không phải đặt bất kỳ tùy chọn nào.


Họ dường như đang cố gắng khắc phục điều này thay vì sử dụng cách giải quyết, vì vậy các phiên bản mới hơn sẽ còn tốt hơn về đầu ra. github.com/tmux/tmux/issues/849
dragon788
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.