깨진 파이프가 더 이상 프로그램을 종료하지 않습니까?

StackOverflow https://stackoverflow.com/questions/103016

  •  01-07-2019
  •  | 
  •  

문제

두 프로세스를 파이프하고 파이프의 "출력"에서 하나를 종료하면 첫 번째 프로세스는 "Broken Pipe" 신호를 수신하는 데 사용되며 일반적으로 종료됩니다.예:달리기

$> do_something_intensive | less

그런 다음 종료 더 적은 SuSE8 또는 이전 릴리스에서 반응형 셸로 즉시 돌아가는 데 사용됩니다.내가 오늘 그걸 시도할 때, do_something_집약적 내가 수동으로 죽일 때까지 분명히 계속 실행 중입니다.뭔가 바뀐 것 같아요 (glib ?shell ?) 프로그램이 "깨진 파이프"를 무시하게 만드는 ...

이것에 대한 힌트를 갖고 있는 사람이 있나요?이전 동작을 복원하는 방법은 무엇입니까?왜 변경되었습니까?(또는 왜 항상 여러 의미가 존재했습니까?)

편집하다 :추가 테스트(strace 사용)에서 "SIGPIPE"가 발견되었습니다. ~이다 생성되지만 프로그램이 중단되지는 않습니다.간단한

#include <stdio.h>
int main() 
{
   while(1) printf("dumb test\n");
   exit(0);
}

끝없이 계속될 것이다

--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(1, "dumb test\ndumb test\ndumb test\ndu"..., 1024) = -1 EPIPE (Broken pipe)

언제 더 적은 살해당했습니다.내 프로그램에서 신호 처리기를 확실히 프로그래밍하고 종료되도록 할 수 있지만 SIGPIPE에서 프로그램을 강제 종료하는 일부 환경 변수나 셸 옵션을 더 찾고 있습니다.

다시 수정:이는 tcsh 관련 문제(bash가 올바르게 처리함) 및 터미널 종속(Eterm 0.9.4)인 것 같습니다.

도움이 되었습니까?

해결책 3

귀하의 조언에 감사드립니다. 해결책이 점점 가까워지고 있습니다.

tcsh 맨페이지에 따르면 "로그인하지 않는 쉘은 부모로부터 종료 동작을 상속받습니다.다른 신호에는 쉘이 상위로부터 상속받은 값이 있습니다."

내 제안 단말기 사실 문제의 근본은..SIGPIPE를 무시하면 쉘 자체도 SIGPIPE를 무시합니다.

편집하다: 나는 문제가 Eterm+tcsh에서만 발생하고 Eterm 소스 코드에서 의심스럽게 누락된 신호(SIGPIPE,SIG_DFL)를 발견했다는 확실한 확인을 받았습니다.내 생각엔 사건이 종결된 것 같아.

다른 팁

글쎄요, 리더가 사라진 후 파이프에 쓰려고 하면 SIGPIPE 신호가 생성됩니다.애플리케이션에는 이 신호를 포착할 수 있는 기능이 있지만 그렇지 않은 경우 프로세스가 종료됩니다.

SIGPIPE는 호출 프로세스가 쓰기를 시도할 때까지 생성되지 않으므로 더 이상 출력이 없으면 생성되지 않습니다.

"뭔가 집중적인 일을 하라"는 것이 전혀 바뀌었나요?

Daniel이 언급했듯이 SIGPIPE는 마법의 "파이프가 사라졌습니다" 신호가 아니라 "좋은 시도입니다. 더 이상 해당 파이프를 읽거나 쓸 수 없습니다" 신호입니다.

"뭔가 집중적인 작업 수행"을 제어할 수 있는 경우 회전할 때 "진행률 표시기" 출력을 작성하도록 변경할 수 있습니다.이렇게 하면 적시에 SIGPIPE가 발생합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top