Czy jest jakiś sposób, aby zapobiec zawieszeniu się tmux, gdy do terminalu jest wysyłanych dużo tekstu?

W sesji tmux wewnątrz xterm, gdy program generuje dużo danych wyjściowych (jak cat very_long_filecała sesja na chwilę zamrożona. Nawet po naciśnięciu Ctrl-C nic nie jest przerywane. Prawdopodobnie dlatego, że tmux jest zamrożony i nie przekazuje Ctrl-C do program generujący dane wyjściowe. Czy można temu zapobiec.

Prawidłowym rozwiązaniem jest sprawdzenie opcji c0- * tmux, aby spróbować ograniczyć wydajność. Przyczyną tego problemu jest to, że dane są wysyłane do terminala szybciej niż może to wyświetlić, więc ograniczenie prędkości jest jedynym sposobem.

Nadal mam ten problem w tmux 1.6-2 na Ubuntu 12.10. Jednym z rozwiązań, które znalazłem, jest oderwanie się od sesji (przedrostek + d), a następnie ponowne podłączenie ( tmux attachdobry kandydat na szybki alias powłoki). Wygląda na to, że tmux faktycznie reaguje pod maską --- możesz potwierdzić, że twój proces został zabity natychmiast za pomocą ctrl-c --- to tylko rysunek, który blokuje. Detatch działa natychmiast, a po ponownym podłączeniu rysunek przeskoczy do końca.

O ile wiem, nie ma sposobu, aby temu zapobiec w obecnych wydaniach, ale niektóre prace są w toku. Niektóre łatki można znaleźć na liście mailingowej tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689 .

Dobrym słowem kluczowym do wyszukiwania w Internecie jest „kontrola przepływu”.

Niestety, opcje ograniczenia prędkości c0- * zostały usunięte od wersji tmux 2.1 (dziennik zmian ). O ile mi wiadomo, jedynym sposobem na dostosowanie ograniczenia prędkości jest aktualizacja zmiennych wpływających na to w kodzie źródłowym (tmux.h):

„ READ_SIZE to maksymalny rozmiar danych do przechowywania z pty (wysoki znak wodny zdarzenia). READ_BACKOFF to ilość danych oczekujących na wysłanie do tty, zanim odczyty pty zostaną wycofane. READ_TIME to czas, po jakim należy się wycofać przed następny odczyt (w mikrosekundach), jeśli tty jest powyżej READ_BACKOFF. "

Gdzie znajdziesz wartości domyślne: (od tmux v2.2):

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

Odpowiedź https://superuser.com/a/589896/311481 działa dobrze. Używam następujących wartości:

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

Kolejna wskazówka: jeśli używasz ssh w ramach tmux, użyj zamiast tego mosh: http://mosh.mit.edu/ Zachowuje się mądrzej, jeśli chodzi o wyświetlanie wyników programów. W razie potrzeby próbuje wyświetlić ostatnie półprodukty upuszczające półprodukty. Tak więc tmux nigdy się nie zawiesi, jeśli w jego oknach wygenerowanych zostanie wiele wyników z sesjami mosh w środku.

W przeciwieństwie do SSH, protokół mosh oparty na UDP z wdziękiem radzi sobie z utratą pakietów i ustawia liczbę klatek na podstawie warunków sieciowych. Mosh nie wypełnia buforów sieciowych, więc Control-C zawsze działa, aby zatrzymać niekontrolowany proces.

Ponieważ SSP [State Synchronization Protocol, którego używa mosh], działa na warstwie obiektowej i może kontrolować szybkość synchronizacji (innymi słowy, szybkość klatek), nie musi wysyłać każdego bajtu otrzymanego z aplikacji. Oznacza to, że Mosh może regulować ramki, aby nie zapełniać buforów sieciowych, zachowując szybkość połączenia i upewniając się, że Control-C zawsze działa szybko. Protokoły, które muszą wysyłać każdy bajt, nie mogą tego zrobić.

Wypróbuj inny emulator terminala. W RedHat 6.5 konsola (KDE) nie ma problemu z blokowaniem (tmux 2.3 i master); jednak zarówno xterm, jak i terminal gnomów doświadczają złego zamrażania.