손상된 파이프로 인해 Unix 프로세스가 종료되는 원인은 무엇입니까?

프로세스는 남아 있는 판독기가 없는 SOCK_STREAM 유형의 파이프(이름이 지정되거나 지정되지 않은) 또는 소켓에 쓰려고 시도할 때 SIGPIPE를 수신합니다.

이는 일반적으로 원하는 동작입니다. 전형적인 예는 다음과 같습니다.

find . | head -n 1

find종료한 후 head(읽기 위해 열려 있던 해당 파이프의 유일한 파일 설명자를 닫은 후) 계속 실행하고 싶지 않습니다 .

명령 은 yes일반적으로 이 신호에 의존하여 종료됩니다.

yes | some-command

"y"는 명령이 종료될 때까지 기록됩니다.

이는 명령이 종료될 때뿐만 아니라 모든 판독기가 파이프에서 fd 읽기를 닫을 때도 발생합니다. 존재하다:

yes | ( sleep 1; exec <&-; ps -fC yes)
      1 2       1        0

서브쉘이 명시적으로 stdin을 닫은 후에는 파이프에서 1(서브쉘), 2(서브쉘 + 절전), 1(서브쉘), 0 fd 읽기가 발생하며 이 시점에서 yesSIGPIPE가 수신됩니다.

위에서 대부분의 쉘은 pipe(2)while 을 ksh93사용 socketpair(2)하지만 이와 관련하여 동작은 동일합니다.

프로세스가 SIGPIPE를 무시하면 쓰기 시스템 호출(일반적 write으로 , pwrite, send... splice)이 오류를 반환합니다 EPIPE. 따라서 손상된 파이프를 수동으로 처리하려는 프로세스는 종종 SIGPIPE를 무시하고 EPIPE 오류에 대해 조치를 취합니다.

(6)

파이프에서 읽을 수 있는 프로세스가 없기 때문에 쓰기가 실패합니다.

설명자를 복사하고 분기하지 않으면 하나의 프로세스만 시작할 수 있지만 일반적으로 파이프에는 판독기와 기록기가 있으며 둘 중 하나가 연결을 닫으면 파이프가 유효하지 않게 됩니다. 명명된 파이프를 사용하는 경우 여러 연결(직렬)을 가질 수 있지만 이러한 의미에서 각 연결은 새 파이프를 나타냅니다. 따라서 스레드나 프로세스의 "파이프"는 파일 설명자와 동의어입니다.

에서 man 7 pipe:

파이프의 읽기 끝을 참조하는 모든 파일 설명자가 닫힌 경우 write(2)는 호출 프로세스에 대해 SIGPIPE 신호가 생성되도록 합니다. 호출 프로세스가 이 신호를 무시하면 write(2)는 오류 EPIPE와 함께 실패합니다.

따라서 "깨진 파이프"는 저자에게 EOF가 독자에게 있는 것과 같습니다.

파이프 손상은 쓰기 프로세스 전에 읽기 프로세스가 종료될 때 발생합니다. 그래서 저는 (6)을 선택하겠습니다.