大量のテキストが端末に出力されるときにtmuxがフリーズするのを防ぐ方法はありますか？

xterm内のtmuxセッションで、プログラムが大量の出力を生成するとき（cat very_long_fileセッション全体がしばらくフリーズするなど。Ctrl-Cを押しても何も中断されません。おそらくtmuxがフリーズし、Ctrl-Cを転送しないため出力を生成するプログラム。これを防ぐ方法はありますか。

正しい解決策は、tmuxのc0- *オプションを調べて、出力をレート制限することです。この問題が存在する理由は、端末に表示されるよりも速くデータが端末に送信されるためです。そのため、レート制限が唯一の方法です。

Ubuntu 12.10のtmux 1.6-2にはまだこの問題があります。私が見つけた回避策の1つは、セッションから外して（prefix + d）、再接続することです（tmux attachクイックシェルエイリアスの良い候補）。tmuxは実際にフードの下で反応するように見えます--- ctrl-cでプロセスが実際に強制終了されていることを確認できます-ブロックしているのは描画だけです。デタッチはすぐに機能し、再アタッチすると、図面は最後までスキップされます。

私の知る限り、現在のリリースではそれを防ぐ方法はありませんが、いくつかの作業が進行中です。tmuxのメーリングリストhttp://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689でいくつかのパッチを見つけることができます。

Webを検索するのに適したキーワードは「フロー制御」です。

残念ながら、tmuxバージョン2.1（changelog）から、レート制限のc0- *オプションは削除されました。私の知る限り、レート制限をカスタマイズする唯一の方法は、ソースコード（tmux.h）で影響する変数を更新することです。

" READ_SIZEは、ptyから保持するデータの最大サイズです（イベントの最高水位標）。 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が使用する状態同期プロトコル]はオブジェクト層で動作し、同期の速度（言い換えれば、フレームレート）を制御できるため、アプリケーションから受信するすべてのバイトを送信する必要はありません。つまり、Moshは、ネットワークバッファーがいっぱいにならないようにフレームを調整し、接続の応答性を維持し、Control-Cが常に迅速に機能することを確認できます。すべてのバイトを送信しなければならないプロトコルはこれを行うことができません。

別の端末エミュレータを試してください。RedHat 6.5では、konsole（KDE）にフリーズの問題はありません（tmux 2.3およびmaster）。ただし、xtermとgnome-terminalはどちらもひどい凍結を経験します。