.png)
오늘 저는 아마도 쉽게 설명할 수 있을 것 같지만 제 입장에서는 상당히 예상치 못한 것을 관찰했습니다. 저는 CentOS(그리고 동일하게 작동하는 RHEL)를 실행하고 있습니다. 터미널에서 bash를 열고 gedit와 같은 하위 프로세스를 시작합니다. 창문이 열리네요, 괜찮아요. 'ps'를 수행하면 gedit에 bash가 부모 프로세스로 있고 자체적으로 gnome-terminal이 부모 프로세스로 있음을 알 수 있습니다. 그런 다음 bash를 중지하면 모든 하위 프로세스도 중지될 것으로 예상됩니다. 하지만 gedit는 계속 실행되고 부모는 1(init)로 변경되었습니다!
나는 쉘을 우아하게 멈추지 않으려 고 노력했지만 열심히 죽였습니다. 같은 결과입니다. 쉘 대신 터미널을 종료하려고 시도했지만 결과는 여전히 동일합니다. X 버튼을 클릭하여 터미널을 닫을 때만 gedit도 닫힙니다.
나는 그런 행동을 기대하지 않았습니다. nohup으로 gedit을 시작하면 놀라지 않을 것입니다. 그러나 nohup이 없어도 ... 왜 계속 살아 있습니까?
어쩌면 누군가가 약간의 빛을 비출 수 있고 거기에서 무슨 일이 일어나고 있는지 알 수 있습니다. 미리 감사드립니다!
답변1
gedit, gvim, google-chrome 등과 같은 프로그램은 자동으로 백그라운드로 포크됩니다. 이를 통해 다음을 입력할 수 있습니다.
gedit /home/msw/ul-answer
새 창을 매핑하고 쉘 프롬프트를 다시 가져옵니다. 이는 나쁜 디자인 선택이 아니며 일반적으로 이를 재정의할 수 있는 옵션이 있습니다. 명령은 gedit -w제어 gvim --nofork터미널에서 분리되지 않으며 쉘 프롬프트를 다시 표시하지 않습니다.
프로그램이 자체적으로 백그라운드를 수행하려면 분기된 다음 상위 프로그램이 종료됩니다. 이렇게 하면 입력한 직후 gedit의 일반 인스턴스가 init(PPID == 1)의 하위 인스턴스가 됩니다.
mplayer나 caliber와 같은 다른 프로그램은 자주 입력되지 않거나 디버그 정보를 제어 터미널에 덤프하는 것을 좋아하기 때문에 자동으로 배경을 설정하지 않습니다.
이상함을 더하다:
이것을 테스트하고 strace 출력 등을 살펴본 후 약간의 시간을 보낸 후 gedit는 자동으로 배경을 설정하지 않는 것으로 보입니다. gvim에 대해 내가 말한 내용은 여전히 유효하며 잠잘 시간이 훨씬 지났으므로 지금은 이 내용을 그대로 두겠습니다.
답변2
터미널 창을 닫으면 커널은 다음을 보냅니다.한숨배쉬에 신호를 보냅니다. 그런 다음 Bash는 각 작업에 SIGHUP을 보내므로 SIGHUP으로 gedit를 종료합니다.
exit또는 Ctrl+를 입력하거나 SIGKILL을 사용하여 bash를 종료하면 D터미널 에뮬레이터는 하위 프로세스가 종료되었음을 확인하고 창을 닫습니다. Gedit는 영향을 받지 않습니다.