bg에 있는 쉘의 포크 하위 프로세스가 상위 프로세스로부터 SIGSTOP 신호를 수신합니까?

bg에 있는 쉘의 포크 하위 프로세스가 상위 프로세스로부터 SIGSTOP 신호를 수신합니까?

~와 연관되다신호 매뉴얼 페이지:

fork(2)를 통해 생성된 하위 프로세스는 상위 프로세스의 신호 구성 복사본을 상속합니다. execve(2) 동안 처리된 신호의 처리는 기본값으로 재설정됩니다. 무시된 신호의 처리는 변경되지 않습니다.

이 경우 자식 프로세스가 전경에서 실행되는지 아니면 배경에서 실행되는지는 전혀 관련이 없습니다.

예:

xterm하위 bg 프로세스로 시작 하면 shell...

xterm &

xterm...그런 다음 bg 프로세스를 시작합니다.

`ls -lR / &`

쉘에서 프로세스를 중지하면 ls프로세스가 중지됩니까?xterm

kill -STOP [pid_of_xterm]

?

아닌 것 같은데 왜 그런지 모르겠습니다.

당신의 도움에 감사드립니다...

답변1

fork(2)를 통해 생성된 하위 프로세스는 상위 프로세스의 신호 구성 복사본을 상속합니다.

이것은 아이들을 의미한다핸들신호는 상위 신호와 동일한 방식으로 처리됩니다. 즉, 동일한 신호 처리기와 동일한 무시된 신호 세트를 갖습니다. 이는 부모 프로세스에 신호를 보내는 것이 어떻게든 자식 프로세스에도 신호를 보내는 것을 의미하지는 않습니다(그렇지 않으면 프로세스를 종료하면 해당 프로세스의 모든 하위 프로세스도 종료됩니다...).

프로세스가능한신호를 하위 항목 중 일부 또는 전부에 전달하도록 신호 처리기를 프로그래밍하는 것이 가능하지만 이는 일반적이지 않습니다. 단, SIGKILL, SIGSTOP 등 처리할 수 없는 시그널에 대해서는 수행할 수 없다. 이를 수행하는 드문 경우는 대화형 셸이 SIGHUP을 실행 중인 작업에 전파하는 경우입니다.

귀하의 예에서 ls 프로세스가 쉘의 하위 프로세스이고 쉘이 xterm의 하위 프로세스인 경우 xterm 프로세스에 STOP 신호를 보내면 xterm 프로세스만 중지됩니다. 쉘이나 ls에는 영향을 미치지 않습니다. 어느 시점에서 ls는막힌터미널이 데이터를 읽지 못하기 때문에 터미널에 쓰려고 합니다. 이는 writels 프로세스의 시스템 호출이 신호와 관계없이 오랜 시간이 걸린다는 것을 의미합니다.

부모-자식 관계로 프로세스 그룹에 시그널을 전달하는 방법이 있는데 이는 시그널을 받는 사람이 아니라 호출하는 사람에 의해 결정되며, 프로세스 그룹은 반드시프로세스 그룹. 프로세스 그룹의 목적은 작업이 여러 프로세스(예: 파이프)로 구성되어 있더라도 전체 셸 작업에 신호를 보낼 수 있도록 하는 것입니다.

관련 정보