SIGHUP 이상한 행동

SIGHUP 이상한 행동

문맥:

bash&예를 들어 리디렉션 없이 프로세스를 실행하고 있습니다 ./foo. 프로세스가 실행 중입니다 while(1). 즉, 영원히 실행됩니다. 또한 프로세스 SIGHUP를 획득하는 동안 프로세스가 무시됩니다 . 즉, 종료되지 않습니다.

프로세스 SIGHUP에 보내면 내 프로세스에도 보내집니다. 그러면 내 프로세스는 신호를 기록하고 작업을 계속합니다.bashSIGHUP

내 이해:

SIGHUP나는 답변을 통해 이해를 쌓았습니다.여기. 내 경우에는 bash프로세스가 종료되기보다는 차단되어야 한다고 이해합니다 .

질문:

그러나 그것은 진실이 아니다. bash프로세스가 계속되면 프로세스가 종료됩니다. 하지만 이제는 bash프로세스 가 아닌 /lib/systemd/systemd --user새로운 부모가 됩니다.

환경 및 기타 세부정보:

Linux lap-0117 5.4.0-87-generic #98~18.04.1-Ubuntu SMP Wed Sep 22 10:45:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

답변1

이것은 정상입니다.

SIGHUP은 일반적으로 제어 터미널이 사라질 때 쉘로 전송되기 때문에(즉, 이는 Unix에서 몇 안되는 자원 회수 인터페이스 중 하나임) 터미널이 없는 쉘은 의미가 없기 때문에 쉘이 종료됩니다.

쉘 자체는 SIGHUP을 처리하고 신호 처리기는 SIGHUP을 모든 백그라운드 프로세스에 전달하여 제어 터미널이 사라졌다는 사실도 알립니다. 기본 핸들러를 떠나는 모든 프로세스는 여기서 종료됩니다. 일반적으로 이는 터미널이 필요한 쉘 명령입니다.

예를 들어, 이 메커니즘은 이를 사용하여 로그 파일을 본 다음 터미널 창을 닫을 때 tail -f정리됩니다 . 셸과 tail그 안에서 실행되는 명령은 상호 작용할 터미널이 없기 때문에 쓸모 없게 되어 종료됩니다.

일반적으로 "고아" 프로세스는 PID 1에 연결됩니다. PID 1이 언제든지 SIGCHLD를 처리하고 하위 프로세스의 종료 코드를 수집할 수 있는 유일한 프로세스이기 때문입니다. 아마도 systemd는 여기서 흥미로운 일을 하고 있을 것입니다. 이를 systemd의 사용자 인스턴스에 연결하는 것인데, 이는 또한 이 계약을 이행합니다.

관련 정보