sed 출력을 동일한 입력 파일로 리디렉션하면 시스템이 응답하지 않는 이유는 무엇입니까?

내가하려고했던 sed큰 파일 (1백메가바이트)에서 몇 가지 키워드를 대체 할 수 있습니다. -i(inplace) 옵션 을 알지 못했기 때문에 첫 번째 시도는 다음과 같이 리디렉션하는 것입니다.

sed 's/original/edited/g' file.log >> file.log

그 후에 일어난 일은 내 PC가 멈추고 키보드 입력이 거의 없다는 것입니다. 다른 콘솔 Ctrl+ Alt+를 시도했지만 F1사용자 이름을 천천히 입력 한 후에도 중지되었습니다. 키보드가 없으면 기계를 하드웨어로 재설정하는 것이 유일한 방법이었습니다. 로그인 한 후 file.log가 약 8GB라는 것을 알았습니다.

그 명령을 실행했을 때 시스템이 응답하지 않는 이유와 시스템 수준에서 경고를 트리거하고 문제를 일으키는 프로세스를 종료시키는 메커니즘이 존재하는지 이해하고 싶습니다.

command-line sed

— 제왕 파촌
소스

이것이 단일 코어 머신입니까? 이것이 현대 컴퓨터를 무릎에 가져다 놓아야한다는 것은 매우 이상하게 보입니다. 디스크를 가득 채웠습니다. 코어 중 하나의 100 %를 사용했습니다. 그러나 전체 충돌?

— terdon

그 파일에 특이한 점이 있습니까? 이것이 문제가되지 않으면, 내용을 pastebin에 게시 할 수 있습니까?

— Sergiy Kolodyazhnyy

또한 메모리 용량은 얼마입니까? 당신은 우리에게 출력을 제공 할 수 free -h 있습니까?

— Sergiy Kolodyazhnyy

파일을 변경할 때 스트림 편집기를 먼저 사용하는 이유는 무엇입니까? 부작용 ex -sc '%s/original/edited/ge|x' file.log없이 UNIX 관용적 인 방식으로 원하는 것을해야합니다 sed -i.

— David Ongaro

사람들이 제공하는 방법 중 하나를 사용하여 올바르게 수행하더라도 활성 프로세스에 속하는 로그 파일에 이런 종류의 작업을 수행하는 것이 문제가 될 수 있습니다.

— Random832

답변:

이미 언급했듯이 >>파일에 추가되므로 sed명령은 출력 된 줄을 읽은 다음 더 출력합니다. 파일을 그 자리에서 바꾸려면 >여전히 작동하지 않지만 sed의 -i옵션을 알고 있습니다.

그러나 스트림으로 읽고있는 파일에 추가하고이 패스를 한 번만 수행 sponge하려면 moreutils패키지 에서 사용하는 것이 좋습니다 .

sed 's/original/edited/g' file.log | sponge >> file.log

spongeEOF까지 stdin에서 메모리로 읽은 다음 모든 내용을 stdout에 덤프하므로 sed파일 끝을 누르고 읽은 것을 멈추고 닫은 다음 스폰지가 추가를 시작합니다.

— ymbirtt
소스

sponge알고있는 유용한 유틸리티이지만 sed이미 -i옵션이 -i[SUFFIX], --in-place[=SUFFIX], edit files in place (makes backup if SUFFIX supplied)있습니다.

— Joshua Taylor

@JoshuaTaylor, OP가 >>대신을 >(를) 대체하는을 (를) 사용하고있었습니다. 물론 OP가 -i게시물에서 구체적으로 언급 했으며 이보다 훨씬 일반적인 사용 사례 인 것처럼 보이지만 OP가 게시 한 특정 작업이 너무 많은 문제없이 가능하다는 것을 지적 할 가치가 있다고 생각했습니다. 확실히 당신이하고 싶은 일입니다.

— ymbirtt

나는 그것이 대답 의 열쇠이기 때문에 여기에 언급했다 . 그건 내가 말했다 오전 에 대해 배울 수있는 진정으로 행복 스폰지 ; 내 도구 상자를위한 새로운 도구이며이를위한 공감대가 필요합니다.

— Joshua Taylor

아! 내가 참조. 나는 그것을 좀 더 명확하게하기 위해 대답을 조정할 것입니다. 당신이 즐길 경우에도 sponge, 한번보세요 vipe. moreutils당신이 결코 알지 못했던 것들로 가득 찬 마법의 포장

— 일뿐입니다

귀하의 sed명령은에 추가 된 파일을 읽으려고했다. 파일 끝에 도달하지는 않지만 많은 CPU 시간을 소비합니다. 이것이 ^ C (인터럽트 전류 프로세스)가 발명 된 이유입니다.

— waltinator
소스

나는 ^ C가 거기에있는 선택권이라고 생각하지 않는다. 깜빡이는 커서가없는 HALT에 갔다!

— EKons

당신이 읽은 파일에 다시 추가하는 것은 결코 증가하는 파일로 끝날 것이기 때문에 결코 좋은 생각이 아닙니다. 실제로 파일에 다시 쓰려면 -i플래그를 사용해야합니다 .

sed -i 's/original/edited/g' file.log

또는 변경을 수행하기 전에 백업을 작성하려는 경우 파일 접미 부를 -i플래그에 추가 할 수 있습니다 .

sed -i.bak 's/original/edited/g' file.log

이것은 호출 된 파일을 생성 한 file.log.bak다음 변경을 수행합니다. 여러분이 읽는 파일에 추가하려고하면 프로그래머 슬랭에서 데이터 레이스를 호출합니다. 여기서 동일한 데이터 소스에 대해 다른 프로세스가 입력 또는 출력됩니다. . 이것이 또한 기계가 정지 한 이유입니다.

— Videonauth
소스

OP의 질문도 다루지 않기 때문에 이것이 정답이라고 생각합니다.

"I really would like to understand why the execution of that command was able to make the system so unresponsive, and if mechanisms exist at the system level to trigger alerts and kill the offending process?"

— Steve

@Steve 왜 중단했는지에 관해서는 언급했지만 두 번째 부분은 옳습니다. 나는 이것에 대한 답을 알지 못했기 때문에 그것을 다루지 않았습니다. 우리는 대화 토론 후에 명령을 광범위하게 테스트했으며 다른 시스템과 운영 체제에서 완전히 다른 결과를 얻었습니다. 예 : 아치가있는 머신에서는 파일이 영원히 커질 수 있지만 머신이 응답하지 않습니다. 내 우분투 컴퓨터에서 프로세스를 죽일 기회없이 질문자와 동일한 결과를 얻었습니다. 우분투 VM에서 동일한 것을 테스트하는 두 번째 머신도 같은 정지 상태가되었습니다.

— Videonauth

strace다른 측면 didtn에 전체 프로세스의 내 컴퓨터에서와 다른 사용자의 컴퓨터에 결과이 재현. 물론 응답하지 않는 응용 프로그램을 종료 할 수있는 메커니즘이 있지만 컴퓨터가 응답하지 않는 경우 한 가지 옵션 만 사용하여 재설정 할 수 있습니다. 나는 여전히 이것에 대해 테스트하고 있으며 설명 된 동작을 일으키는 원인을 완전히 이해하지 못하기 전에이 부분을 해결할 수 없습니다.

— Videonauth

IO를 우선시하는 다른 스케줄러 또는 시스템 간의 디스크 / 파일 시스템 드라이버의 차이와 같이 커널 구성의 차이 일 수 있습니다. 여러분의 조사를 보는 것이 좋습니다. 좋은 정보입니다.

— Steve

다른 데이터 포인트에 관심이 있다면; 나는 상당히 작은 파일로 CentOS 컴퓨터에서 이것을 시도했으며, 아래의 스폰지 솔루션과 정확히 같은 일을했습니다. 작은 파일 sed의 경우 핸들을 잡지 않고 전체를 메모리에 버퍼링 한 다음 닫습니다. OP에서와 같이 ~ 100MB 파일을 사용하면 무한대로 커지지 만 시스템을 손상시키지 않았습니다.

— ymbirtt