В сеансе tmux внутри xterm, когда программы генерируют много выходных данных (например, cat very_long_file весь сеанс временно заморожен). Даже если я нажму Ctrl-C, ничто не будет прервано. Предположительно, потому что tmux заморожен и не передает Ctrl-C программе, генерирующей вывод. Есть ли способ предотвратить это.
35
6 ответов
20
У меня все еще есть эта проблема в tmux 1.6-2 на Ubuntu 12.10. Один из обходных путей, который я нашел, состоит в том, чтобы отсоединиться от сеанса (префикс +d), а затем снова присоединить (tmux attach , хороший кандидат на быстрый псевдоним оболочки). Похоже, что tmux на самом деле отзывчив на себя - вы можете подтвердить, что ваш процесс на самом деле немедленно завершен с помощью ctrl-c - это просто рисунок, который блокирует. Detatch работает немедленно, и при повторном присоединении чертеж будет пропущен до конца.
14
Правильное решение - взглянуть на опции c0- * в tmux, чтобы попытаться ограничить скорость вывода. Причина, по которой эта проблема вообще существует, заключается в том, что данные отправляются на терминал быстрее, чем он может их отобразить, поэтому ограничение скорости - единственный способ.
5
Насколько я знаю, нет способа предотвратить это в текущих выпусках, но некоторая работа продолжается. Вы можете найти некоторые исправления в списке рассылки tmux http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689.
Хорошее ключевое слово для поиска в Интернете - "управление потоком".
5
К сожалению, опции ограничения скорости c0- * были удалены с tmux версии 2.1 (changelog). Насколько я знаю, единственный способ настроить ограничение скорости - это обновить переменные, влияющие на него, в исходном коде (tmux.h):
Msgstr " READ_SIZE - максимальный размер данных для хранения из pty (верхний знак события).READ_BACKOFF - это объем данных, ожидающих вывода в tty, прежде чем pty чтения будут отменены. READ_TIME - это как долго отступать перед следующим чтением (в микросекундах), если tty выше READ_BACKOFF. "
Где вы найдете значения по умолчанию: (по состоянию на tmux v2.2):
#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100
4
Ответ https://superuser.com/a/589896/311481 работает отлично. Я использую следующие значения:
setw -g c0-change-trigger 10
setw -g c0-change-interval 250
Другой совет: если вы используете ssh в tmux, используйте вместо этого mosh: http://mosh.mit.edu/ Он ведет себя умнее в отношении отображения вывода программ. Он пытается отобразить последнее состояние экрана, опускающее промежуточные звенья, когда это необходимо. Таким образом, tmux никогда не замерзнет, если в его панелях генерируется много выходных данных, а внутри сеансов mosh.
В отличие от SSH, протокол mosh на основе UDP корректно обрабатывает потери пакетов и устанавливает частоту кадров в зависимости от состояния сети. Mosh не заполняет сетевые буферы, поэтому Control-C всегда работает, чтобы остановить процесс разгона.
Поскольку SSP [State Synchronization Protocol, который использует mosh] работает на объектном уровне и может контролировать скорость синхронизации (другими словами, частоту кадров), ему не нужно отправлять каждый байт, который он получает от приложения. Это означает, что Mosh может регулировать кадры, чтобы не заполнять сетевые буферы, сохраняя скорость отклика соединения и гарантируя, что Control-C всегда работает быстро. Протоколы, которые должны отправлять каждый байт, не могут этого сделать.
0
Попробуйте другой эмулятор терминала. В RedHat 6.5 у konsole (KDE) нет проблемы с зависанием (tmux 2.3 и master); однако, xterm и gnome-Terminal испытывают сильное замораживание.