SIGUSR1이 프로세스를 종료시키는 이유는 무엇입니까?

다른 질문 에서이 의견 에 놀랐습니다 .

USR1 신호를 시작한 후 너무 빨리 dd를 보내면 (예 : bash 스크립트에서 시작한 줄) 실제로 종료됩니다.

아무도 이유를 설명 할 수 있습니까 ?

signals

귀하의 질문에 대한 답변은 아니지만이 단일 라이너를 사용해보십시오 { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobs. 설명하는 효과를 재현하십시오.

— jippie

각 신호에는 "기본 처리"가 있습니다. 프로세스는 해당 신호를 수신 할 때 기본적으로 수행하는 작업입니다. signal(7)매뉴얼 페이지 에는 다음과 같은 표가 있습니다.

Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2

SIGUSR1그리고 SIGUSR2둘 다 기본 조치를 취 Term합니다. 프로세스가 종료됩니다. dd신호를 가로 채기 위해 처리기를 등록하고 신호로 유용한 작업을 수행하지만 너무 빨리 신호를 보내면 처리기를 아직 등록 할 시간이 없으므로 기본 동작이 대신 발생합니다.

— 마이클 Mrozek
소스

이 모호함을 인식 한 것에 대해 두 번 공감할 수 있기를 바랍니다. 명시 적 신호 처리기를 제거하고 난 후에 프로세스가 무작위로 종료되는 것을 봅니다.

— DeaconDesperado

합리적인 시간 (~ 0.5-1 초) 동안 자지 않고이 경쟁 조건을 제어 할 수있는 실용적인 방법이 있습니까? ( strace쉘 스크립트에서 출력을 캡처하고 파싱하는 것과 같은 우스꽝스러운

— Adrian Günter

쉘 스크립트가 제대로 작동했습니다. 그러나 가능성 때문에 갑자기 일을 멈춰라! : 나는 이제 하이퍼 스레딩을 중단했다. kill -s SIGUSR1 $ PARENT_PID를 보내는 서브 프로세스가 너무 빠릅니다. 그랜드 부모는 부모가 정상적으로 종료되었다고 생각하지만 부모는 여전히 루프를 실행하고 있습니다. 이것은 좋은 게시물입니다. 나는 이것을 알아 내려고 노력하면서 대부분의 시간을 보냈습니다.

— Kemin Zhou