SSH 세션에서 실행 중인 프로그램의 출력을 즉시 중지합니다.

나는 일반적으로 키를 사용 하여 종료 less할 수 있도록 출력을 실행합니다 .lessq

$ cmd | less

예

$ cat /dev/urandom | less

   

+ 를 누르면 종료 q되고 Enter일반 터미널로 돌아가서 깨끗하고 깔끔하게 유지됩니다.

왜 이런 일이 발생합니까?

문제는 모니터의 출력과 함께 대기 중인 일부 버퍼(STDOUT용)가 있다는 것입니다. 이러한 버퍼는 너무 빨리 채워지므로 중지할 만큼 빠르게 중단할 수 없습니다.

                                    

이 효과를 비활성화/제한하려면 STDOUT 버퍼링을 비활성화하면 반응성이 향상되지만 stdbuf원하는 방식으로 작업하려면 이러한 설정을 가지고 놀아야 할 수도 있습니다. STDOUT 버퍼링을 해제하려면 다음 명령을 사용할 수 있습니다.

$ stdbuf -o0 <cmd>

매뉴얼 페이지에는 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원격 측으로 보내면 실행 중인 프로그램이 중단됩니다 . 프로그램이 존재하고 쉘은 프롬프트를 다시 표시하기 위해 문자를 보냅니다. 프롬프트가 표시되기 전에 먼저 버퍼링되어 전송된 모든 데이터가 화면에 표시됩니다.

당신이 요구하는 것은 프로그램이 멈추고 전송 중인 데이터가 어떻게든 사라지는 것입니다. 이미 진행 중이기 때문에 이런 일이 일어날 수 없습니다.

이 데이터가 표시되지 않도록 하는 유일한 방법은 터미널을 종료하고 원격 장치에 다시 연결하는 것입니다. 그러나 이는 버퍼링된 데이터가 표시될 때까지 기다리는 것보다 더 힘들 수 있습니다.

버퍼링에는 여러 수준이 있습니다. Ctrl+ 를 누르면 C프로그램이 터미널로의 데이터 전송을 중지합니다. 이는 터미널 에뮬레이터에 아직 표시되지 않은 데이터에는 영향을 미치지 않습니다.

매우 빠른 속도로 데이터를 표시하면 단말기가 따라가지 못하고 지연이 발생합니다. 이것이 바로 여기서 일어나는 일입니다. 텍스트를 표시하는 것은 이러한 난수를 생성하는 것보다 훨씬 더 비쌉니다. 예, 비트맵 글꼴을 사용하더라도 암호화 품질 난수를 생성하는 것은 비교해 보면 매우 저렴합니다. (방금 내 컴퓨터에서 이것을 시도했는데 X 프로세스가 CPU를 xterm몇 %로 포화시켜 cat간신히 1%에 도달했습니다(난수 생성에서 고려). 이는 비트맵 글꼴을 사용할 때입니다.)

지금 중지하려면 터미널 에뮬레이터를 종료하십시오. 이를 원하지 않으면 적어도 창을 최소화하십시오. xterm과 같은 스마트 터미널 에뮬레이터는 창을 매핑하지 않으므로 X CPU 시간이 절약되므로 가비지 표시가 더 빨리 완료됩니다. X 서버는 우선순위가 높으므로 xterm이 백그라운드에서 데이터를 처리하는 동안 이는 컴퓨터의 응답성에 큰 영향을 미칩니다.

이 모든 작업이 원격 셸에서 수행되면 생성된 데이터가 cat먼저 SSH 연결을 거쳐야 하기 때문에 대기 시간이 더욱 악화됩니다. Ctrl+ 를 눌러 SSH를 통해 연결해야 합니다 C. 우선 순위가 더 높지만(대역 외 전송) 여전히 시간이 걸리며 그 동안 더 많은 출력이 누적됩니다. SSH 연결을 닫는 것( Enter다음을 눌러 수행 할 수 있음) 외에는 ~.전송 중인 데이터를 억제할 수 있는 방법이 없습니다.

저도 같은 문제가 있었고 여기에 나온 답변이 만족스럽지 않아서 더 자세히 알아봤습니다. 다른 사람들은 귀하의 명령이 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는 예상대로 작동하여 버퍼링된 내용이 거의 없기 때문에 즉시 출력을 종료합니다.