쉘의 하위 프로세스로 직접 전송되는 터미널 관련 신호와 쉘 프로세스를 통해 간접적으로 전송되는 신호는 무엇입니까?

쉘의 하위 프로세스로 직접 전송되는 터미널 관련 신호와 쉘 프로세스를 통해 간접적으로 전송되는 신호는 무엇입니까?

Giles의 답변을 이해한다면다양한 신호가 전송되는 원인은 무엇입니까?맞습니다. 터미널에서 실행되는 셸 프로세스의 작업 제어와 관련된 몇 가지 신호가 있습니다.

  • 키 누르기 알림: SIGINT, SIGQUIT, SIGTSTP

  • SIGSTOP, SIGCHLD, SIGCONT,

  • SIGTTIN 및 SIGTTOU

  • SIGWINCH 및 SIGHUP.

어떤 터미널 관련 신호가 먼저 터미널의 쉘 프로세스에 도달하지 않고 쉘의 하위 프로세스로 직접 전송되는지, 어떤 터미널 관련 신호가 먼저 터미널의 쉘 프로세스로 전송되고 쉘이 하위 프로세스로 다시 전송되는지 알고 싶습니다.

예를 들어, 가장 일반적으로 사용되는 두 가지 신호에 대해 다음은 올바른 것입니까?

SIGHUP은 먼저 셸 프로세스로 전송된 다음 포그라운드 또는 백그라운드에 있는지 여부(즉, nohup차이를 만들 수 있는 경우)에 관계없이 셸의 모든 하위 프로세스로 다시 전송됩니다.

Ctrl-C를 누를 때 SIGINT에 해당되는 내용은 다음과 같습니다.

  • 터미널 드라이버는 터미널에서 실행 중인 상위 셸 프로세스가 아닌 전경 그룹의 프로세스에만 SIGINT를 보냅니다. 따라서 상위 셸 프로세스는 SIGINT를 처리할 필요가 없습니다.

  • 터미널 드라이버는 터미널에서 실행 중인 셸 프로세스에 SIGINT를 보내고, 셸 프로세스는 이를 포그라운드 그룹의 프로세스에 다시 보내 SIGINT를 처리합니다.

Stéphane Chazelas의 답변을 이해한다면https://unix.stackexchange.com/a/384702/674그렇죠, 첫 번째가 맞나요?

감사해요!

답변1

대화형 셸의 포그라운드에서 작업을 실행하면 해당 작업(해당 프로세스 그룹)의 프로세스만 SIGINT(셸이 아닌 커널에서 전송)를 받습니다 ^C.

실행 중인 포그라운드 작업이 없는 경우, 즉 프롬프트에서 쉘은 명령줄 입력을 기다리는 동안 포그라운드에 있습니다. 따라서 키를 누르면 ^CSIGINT 신호가 쉘에 전송되며, 쉘은 일반적으로 현재 입력된 텍스트를 취소하는 것으로 처리하며 키 또는 완성 위젯의 일부로 호출된 명령을 종료할 수도 있습니다. 여기에 자신만의 핸들러를 추가할 수도 있습니다.


노트

1 다른 명령도 병렬로 실행하는 스크립트의 일부로 쉘이 시작되면 다른 프로세스가 동일한 프로세스 그룹에 있을 수 있습니다. 대화형 쉘은 시작 시 자체적으로 새로운 프로세스 그룹을 생성하려고 시도하지만(그리고 이를 전경 프로세스 그룹으로 설정) 해당 프로세스가 이미 프로세스 그룹 리더인 경우에는 그렇게 하지 못할 수도 있습니다. 이렇게 하면:

bash -c ': <(sleep 1000); exec bash'

그런 다음 Ctrl+C해당 쉘에 대한 프롬프트를 누르면 쉘 도 종료된다는 bash것을 알 수 있습니다 .sleep

sleep다음과 같이 실행하면 관찰되지 않습니다.

sh -c 'sleep 1000 & exec bash'

이 경우 sh비동기 명령에 대한 SIGINT는 명시적으로 무시됩니다 sleep(SIGINT 처리는 실행 전에 SIGIGN으로 설정됨 sleep).

관련 정보