Остановка вывода от прогона программы на сессии SSH ТЕПЕРЬ

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

References

• Turn off buffering in pipe

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

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

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

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

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

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

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

  pgrep cat | awk '{print "pstree -sp "$1}" | sh | grep sshd

  answer with a output like

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

  В данном случае, после того, как тебе придется убить только кошку PID: убить 23131

Примечание:

• Так как только что сообщили меньше безопаснее.

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

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

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

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