Остановка вывода из программы, запущенной в сеансе SSH СЕЙЧАС

проблема

Я выполняю команду, которая выводит много информации через SSH. Например, я безрассудно добавляю отладочную информацию в цикл, который выполняется миллион раз, или просто запускаю cat /dev/urandomдля ударов.

Терминал залит информацией.

Я хочу завершить команду как можно скорее и исправить мою программу. Мне все равно, что это печатает. Дело в том, что я нажимаю Ctrl+ CКАК МОЖНО СКОРЕЕ (в приведенном выше примере я нажал ее сразу после запуска команды), но все равно требуется время для печати всей информации, которая мне даже не нужна .

Что я пробовал

Я пытался нажать Ctrl+ Cтак сильно, что получился забавный результат, когда терминал наконец догнал:

OUTPUT HERE^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
^C^C

^C^C^C^C^C^C^C^C^C^C^C
^C^C^C^C^C^C^C^C^C^C
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
^C^C^C^C^C^C^C
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
^C^C^C^C^C^C^C^C^C^C^C^C^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C
rr-@burza:~/xor$ ^C

Я также читал о Ctrl+, Sкоторый, по-видимому , используется, чтобы сказать терминалу «остановить вывод, мне нужно наверстать упущенное», но, видимо, это ничего не делает.

Разные детали

Я не хотел бы изменять команду, которую я запускаю, чтобы я мог спасти себя в любой ситуации, даже если я не помню, чтобы программа, которую я запускаю, могла закончиться таким образом.

Мой SSH-клиент работает в Cygwin ( CYGWIN_NT-6.1-WOW64 luna 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin) в MinTTY с установленным типом терминала xterm-256color.

SSH сервер работает на Debian ( Linux burza 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 i686 i686 GNU/Linux).

Некоторые из этих выходных данных будут помещены в буфер. Вы отправляете свой Ctrl+ Cна удаленный конец, который прерывает работающую программу. Программа существует, и оболочка отправляет символы, чтобы снова показать вам приглашение. Перед тем, как отобразится подсказка, ваш экран сначала покажет все данные, которые были буферизованы и уже находятся на пути к вам.

То, что вы просите, чтобы программа остановилась и данные в пути как-то исчезли. Этого не может быть, потому что он уже в пути.

Единственный способ убедиться, что вы не видите эти данные, - это выйти из терминала на своем конце, а затем снова подключиться к удаленному - но это, вероятно, гораздо больше усилий, чем ожидание отображения буферизованных данных.

Я обычно запускаю вывод, lessчтобы lessвместо него можно было убить его, используя qключ.

$ cmd | less

пример

$ cat /dev/urandom | less

После нажатия q+ Enterон выйдет и вернется к своему обычному терминалу, оставив его красивым и чистым.

Почему это происходит?

Проблема, с которой вы сталкиваетесь, состоит в том, что есть буферы (для STDOUT), которые ставятся в очередь с выводом вашего дисплея. Эти буферы заполняются так быстро, что вы не можете прервать его достаточно быстро, чтобы остановить его.

Чтобы отключить / ограничить этот эффект, вы можете отключить буферизацию STDOUT, которая должна сделать вещи более адаптивными при использовании stdbuf, но вам, вероятно, придется поиграть с этими настройками, чтобы все получилось так, как вы хотите. Чтобы отменить буфер STDOUT, вы можете использовать эту команду:

$ stdbuf -o0 <cmd>

Страница man для stdbufполучения подробной информации о доступных вариантах:

    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, озаглавленный: буферизация в стандартных потоках . Это даже включает в себя хорошие картинки.

Ссылки

• Отключить буферизацию в трубе

Есть несколько уровней буферизации. Когда вы нажимаете Ctrl+ C, программа не передает данные в терминал. Это не влияет на данные, которые эмулятор терминала еще не отображал.

Когда вы отображаете данные на очень высокой скорости, терминал не может идти в ногу и будет зависать. Вот что здесь происходит: отображение текста обходится намного дороже, чем создание этих случайных чисел. Да, даже с использованием растрового шрифта - создание случайных чисел криптографического качества по сравнению с ним намного дешевле. (Я только что попробовал на своей машине, и процесс X насыщал процессор, xtermвзяв несколько% и cat(с учетом генерации случайных чисел) едва достигнув 1%. И это с растровым шрифтом.)

Если вы хотите, чтобы это прекратилось сейчас, убейте эмулятор терминала. Если вы не хотите этого делать, хотя бы сверните окно; интеллектуальные эмуляторы терминала (такие как xterm) не будут отображать окно, которое экономит время процессора X, поэтому мусор будет отображаться быстрее. Х-сервер имеет высокий приоритет, поэтому это сильно повлияет на скорость отклика вашей машины, пока xterm обрабатывает данные в фоновом режиме.

Когда все это происходит в удаленной оболочке, задержка становится еще хуже, потому что данные, catкоторые должны быть получены, должны сначала пройти через соединение SSH. Ваше нажатие Ctrl+ Cтакже должно пройти через соединение SSH; он получает несколько более высокий приоритет (он отправляется вне полосы), но это все равно занимает некоторое время, в течение которого накапливается больше выходных данных. Невозможно подавить данные в пути, кроме закрытия SSH-соединения (что можно сделать, нажав Enterзатем ~.).

Это должно быть достаточно , чтобы найти путь к killв catкоманде.
Для следующих предложений вам может понадобиться второе открытое соединение ssh.

• Редко CTRL+zможет быть более эффективным, чем CTRL+c: он может ответить быстрее. После этого вы приостанавливаете действие команды, которую можете убить, kill %1или любой другой номер задания.
  Это в надежде на то, что вы все еще можете прочитать что-нибудь с экрана (случайный двоичный текст может легко испортить ваш набор символов).
  Как вспомнил Жиль, если вы свернули окно, вероятно, система будет быстрее читать запрос на прерывание, чем вы, чтобы завершить процесс. Так что приостановить / прервать, минимизировать, немного подождать, максимизировать снова, тоже может быть решением.
  Конечно, через ssh-соединение я ожидаю, что вам нужно подождать некоторое время.

• В другом терминале / сеансе вы можете спросить pgrep cat(была ли вызвана команда cat) и определить, что процесс cat использует больше вашего процессора. Вы можете определить это с большей точностью с помощью pstree:

  пгреп кот | awk '{print "pstree -sp" $ 1}' | ш | grep sshd

  ответ с выводом, как

  INIT (1) ───sshd (1062) ───sshd (22884) ───sshd (22951) ───bash (22957) ───cat (23131)

  В этом случае после того, как вам нужно убить только кота PID: убить 23131

Замечания:

• Как только что сообщалось less , безопаснее.

У меня была та же проблема, и я не был удовлетворен ответами здесь, поэтому я копал глубже. Другие уже упоминали, что ваша команда выводит данные быстрее, чем ваш 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

Возможно, вы захотите немного уменьшить СКОРОСТЬ, если время от времени скорость вашего соединения немного падает. Если он провалится, поведение вернется к проблеме, неотзывчивый Ctrl-C.

Дополнительный псевдоним удушенного кота:

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

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

# usage: tcat <FILENAME>

Теперь Ctrl-C работает, как и ожидалось, немедленно убивая вывод, так как очень мало, если таковые имеются, буферизуется.

В Linux есть программное обеспечение, которое решает именно эту проблему (пару других вещей тоже). Вы также можете вызвать его из эмулятора терминала в Windows (вы, кажется, используете Windows?).

Попробуйте mosh , замену двоичного файла SSH. Он работает точно так же, как SSH (вы можете сделать mosh user@hostnameвместо него, ssh user@hostnameи он будет работать точно так, как вы ожидаете, даже будет выполнять аутентификацию с закрытым ключом и т. Д.).

Он в основном выполняет отдельный процесс на сервере, который буферизует пакеты. Поэтому, когда вы нажимаете Ctrl + C на mosh, он передает это на удаленный сервер, который затем прекращает отправку дополнительной информации. Кроме того, он также будет предсказывать результат нажатия клавиш, экономя вам пару миллисекунд при каждом нажатии клавиши.

Недостаток: в настоящее время невозможно прокрутить историю при использовании mosh.