SSHセッションで実行中のプログラムからの出力を停止する

Question 1

私は通常、キーを使用する代わりlessにを介してそれを強制終了できるように、出力を実行します。lessq

$ cmd | less

例

$ cat /dev/urandom | less

q+を押すとEnter終了し、通常のターミナルに戻り、きれいな状態になります。

なぜそうなるのでしょうか?

発生している問題は、ディスプレイの出力でキューに入れられているバッファ (STDOUT 用) があることです。これらのバッファは非常に早くいっぱいになるため、停止するのに十分な速さで中断することができません。

ss #1

この効果を無効/制限するには、STDOUT バッファリングを無効にすることができます。これにより、を使用すると応答性が少し向上しますstdbufが、希望どおりの結果を得るにはこれらの設定を試してみる必要があるでしょう。STDOUT のバッファリングを解除するには、次のコマンドを使用します。

$ stdbuf -o0 <cmd>

stdbuf利用可能なオプションの詳細については、man ページを参照してください。

    If MODE is 'L' the corresponding stream will be line buffered.  This 
    option is invalid with standard input.

    If MODE is '0' the corresponding stream will be unbuffered.

    Otherwise MODE is a number which may be followed by one of the 
    following: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so
    on for G, T, P, E, Z, Y.  In this case the corresponding stream will be 
    fully buffered with the  buffer  size  set  to  MODE
    bytes.

バッファリングの仕組みに関する背景情報については、次のタイトルの Pixel Beat の記事をご覧になることを強くお勧めします。標準ストリームでのバッファリング素敵な写真も載っています。

参考文献

パイプ内のバッファリングをオフにする

Answer

私は通常、キーを使用する代わりlessにを介してそれを強制終了できるように、出力を実行します。lessq

$ cmd | less

例

$ cat /dev/urandom | less

q+を押すとEnter終了し、通常のターミナルに戻り、きれいな状態になります。

なぜそうなるのでしょうか?

発生している問題は、ディスプレイの出力でキューに入れられているバッファ (STDOUT 用) があることです。これらのバッファは非常に早くいっぱいになるため、停止するのに十分な速さで中断することができません。

ss #1

この効果を無効/制限するには、STDOUT バッファリングを無効にすることができます。これにより、を使用すると応答性が少し向上しますstdbufが、希望どおりの結果を得るにはこれらの設定を試してみる必要があるでしょう。STDOUT のバッファリングを解除するには、次のコマンドを使用します。

$ stdbuf -o0 <cmd>

stdbuf利用可能なオプションの詳細については、man ページを参照してください。

    If MODE is 'L' the corresponding stream will be line buffered.  This 
    option is invalid with standard input.

    If MODE is '0' the corresponding stream will be unbuffered.

    Otherwise MODE is a number which may be followed by one of the 
    following: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so
    on for G, T, P, E, Z, Y.  In this case the corresponding stream will be 
    fully buffered with the  buffer  size  set  to  MODE
    bytes.

バッファリングの仕組みに関する背景情報については、次のタイトルの Pixel Beat の記事をご覧になることを強くお勧めします。標準ストリームでのバッファリング素敵な写真も載っています。

参考文献

パイプ内のバッファリングをオフにする

Question 2

出力の一部はバッファリングされます。リモートエンドにCtrl+を送信するCと、実行中のプログラムが中断されます。プログラムが終了し、シェルはプロンプトを再度表示するための文字を送信します。プロンプトが表示される前に、バッファリングされて既に送信中のすべてのデータが画面に表示されます。

あなたが求めているのは、プログラムを停止し、転送中のデータを何らかの方法で消去することです。すでに転送中なので、それは起こり得ません。

このデータが表示されないようにする唯一の方法は、自分の端末を終了してリモートに再接続することですが、これはバッファリングされたデータが表示されるのを待つよりもはるかに手間がかかるでしょう。

Answer

出力の一部はバッファリングされます。リモートエンドにCtrl+を送信するCと、実行中のプログラムが中断されます。プログラムが終了し、シェルはプロンプトを再度表示するための文字を送信します。プロンプトが表示される前に、バッファリングされて既に送信中のすべてのデータが画面に表示されます。

あなたが求めているのは、プログラムを停止し、転送中のデータを何らかの方法で消去することです。すでに転送中なので、それは起こり得ません。

このデータが表示されないようにする唯一の方法は、自分の端末を終了してリモートに再接続することですが、これはバッファリングされたデータが表示されるのを待つよりもはるかに手間がかかるでしょう。

Question 3

バッファリングにはいくつかのレベルがあります。Ctrl+を押すとC、プログラムが端末にデータを送信しなくなります。これは、端末エミュレータがまだ表示していないデータには影響しません。

非常に高速にデータを表示する場合、端末は追いつけず、遅延します。ここで起きているのは、テキストの表示がこれらの乱数を生成するよりもはるかにコストがかかるということです。はい、ビットマップフォントを使用した場合でも、暗号品質の乱数を生成することは、それに比べれば非常に安価です。(自分のマシンで試したところ、X プロセスが CPU を飽和させ、xterm数 % を消費し、cat(乱数生成を考慮して) 1 % に達するのがやっとでした。これはビットマップフォントを使用した場合です。)

これを今すぐ停止したい場合は、ターミナルエミュレータを終了します。これを実行したくない場合は、少なくともウィンドウを最小化します。インテリジェントなターミナルエミュレータ (xterm など) はウィンドウをマップしないため、X CPU 時間が節約され、不要なメッセージの表示がより早く終了します。X サーバーは優先度が高いため、xterm がバックグラウンドでデータを処理している間、マシンの応答性に大きな違いが生じます。

これらすべてがリモートシェルで実行されている場合、によって生成されたデータはcatまず SSH 接続を通過する必要があるため、遅延はさらに悪化します。Ctrl+を押すCと、SSH 接続を通過する必要があります。これは、いくらか優先度が高くなります (帯域外で送信されます) が、それでも、より多くの出力が蓄積される間に時間がかかります。SSH 接続を閉じる以外に、転送中のデータを抑制する方法はありません (これは、を押してEnterからを押すことで実行できます~.)。

Answer

バッファリングにはいくつかのレベルがあります。Ctrl+を押すとC、プログラムが端末にデータを送信しなくなります。これは、端末エミュレータがまだ表示していないデータには影響しません。

非常に高速にデータを表示する場合、端末は追いつけず、遅延します。ここで起きているのは、テキストの表示がこれらの乱数を生成するよりもはるかにコストがかかるということです。はい、ビットマップフォントを使用した場合でも、暗号品質の乱数を生成することは、それに比べれば非常に安価です。(自分のマシンで試したところ、X プロセスが CPU を飽和させ、xterm数 % を消費し、cat(乱数生成を考慮して) 1 % に達するのがやっとでした。これはビットマップフォントを使用した場合です。)

これを今すぐ停止したい場合は、ターミナルエミュレータを終了します。これを実行したくない場合は、少なくともウィンドウを最小化します。インテリジェントなターミナルエミュレータ (xterm など) はウィンドウをマップしないため、X CPU 時間が節約され、不要なメッセージの表示がより早く終了します。X サーバーは優先度が高いため、xterm がバックグラウンドでデータを処理している間、マシンの応答性に大きな違いが生じます。

これらすべてがリモートシェルで実行されている場合、によって生成されたデータはcatまず SSH 接続を通過する必要があるため、遅延はさらに悪化します。Ctrl+を押すCと、SSH 接続を通過する必要があります。これは、いくらか優先度が高くなります (帯域外で送信されます) が、それでも、より多くの出力が蓄積される間に時間がかかります。SSH 接続を閉じる以外に、転送中のデータを抑制する方法はありません (これは、を押してEnterからを押すことで実行できます~.)。

Question 4

私も同じ問題を抱えていましたが、ここでの回答に満足できなかったので、さらに深く調べました。他の人がすでに述べているように、コマンドは ssh が処理できるよりも速くデータを出力しているため、データバッファとバッファを停止することはできません。

これを修正するには、コマンド出力を SSH セッションが実行できる最大速度に制限してバッファリングを回避します。これを行うコマンドはすでに存在します。

セットアップでは、まずセッションの最大レートを確認します。

# Get transfer <TIME> of a large file (>10MB preferable)
/usr/bin/time -f "%e" cat <FILENAME>

# Get file <SIZE> in bytes
stat --printf="%s\n" <FILENAME>

# Calculate <RATE>
echo "<SIZE> / <TIME>" | bc

最後に、実際のコマンドをそれに応じて調整します。

<YOUR_COMMAND> | pv -qL <RATE>

例：

/usr/bin/time -f "%e" cat large_reference_file.txt
31.26

stat --printf="%s\n" cat large_reference_file.txt
17302734

echo "17302734 / 31.26" | bc
553510

# Throttle my command to 553510B/s
cat some_other_file.txt | pv -qL 553510

接続速度が時々低下する場合は、RATE を少し下げたほうがよいかもしれません。接続速度が低下すると、Ctrl + C が反応しなくなるという問題が再発します。

オプションのスロットルされた cat エイリアス:

# bash
alias tcat='tcat(){ cat $@ | pv -qL 400k ; }; tcat'

# tcsh
alias tcat 'cat \!* | pv -qL 400k'

# usage: tcat <FILENAME>

今では ctrl-c は期待どおりに動作し、バッファリングされるものがほとんどないため、出力は直ちに終了します。

Answer

私も同じ問題を抱えていましたが、ここでの回答に満足できなかったので、さらに深く調べました。他の人がすでに述べているように、コマンドは ssh が処理できるよりも速くデータを出力しているため、データバッファとバッファを停止することはできません。

これを修正するには、コマンド出力を SSH セッションが実行できる最大速度に制限してバッファリングを回避します。これを行うコマンドはすでに存在します。

セットアップでは、まずセッションの最大レートを確認します。

# Get transfer <TIME> of a large file (>10MB preferable)
/usr/bin/time -f "%e" cat <FILENAME>

# Get file <SIZE> in bytes
stat --printf="%s\n" <FILENAME>

# Calculate <RATE>
echo "<SIZE> / <TIME>" | bc

最後に、実際のコマンドをそれに応じて調整します。

<YOUR_COMMAND> | pv -qL <RATE>

例：

/usr/bin/time -f "%e" cat large_reference_file.txt
31.26

stat --printf="%s\n" cat large_reference_file.txt
17302734

echo "17302734 / 31.26" | bc
553510

# Throttle my command to 553510B/s
cat some_other_file.txt | pv -qL 553510

接続速度が時々低下する場合は、RATE を少し下げたほうがよいかもしれません。接続速度が低下すると、Ctrl + C が反応しなくなるという問題が再発します。

オプションのスロットルされた cat エイリアス:

# bash
alias tcat='tcat(){ cat $@ | pv -qL 400k ; }; tcat'

# tcsh
alias tcat 'cat \!* | pv -qL 400k'

# usage: tcat <FILENAME>

今では ctrl-c は期待どおりに動作し、バッファリングされるものがほとんどないため、出力は直ちに終了します。

SSHセッションで実行中のプログラムからの出力を停止する

問題

私が試したこと

その他詳細

答え1

例

なぜそうなるのでしょうか?

参考文献

答え2

答え3

答え4

関連情報