.png)
오늘 나는 간단한 설명이 있을 수 있지만 나에게는 매우 예상치 못한 것을 관찰했습니다. 나는 CentOS(및 동일하게 작동하는 RHEL)를 실행하고 있습니다. 터미널에서 bash를 열고 gedit와 같은 하위 프로세스를 시작합니다. 창문이 열려있어서 괜찮아요. "ps"를 실행하면 gedit에 bash가 상위 프로세스로 있고 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로 Dbash를 종료하여 bash를 종료 하면 터미널 에뮬레이터는 하위 프로세스가 종료되었음을 인식하고 창을 닫습니다. Gedit는 영향을 받지 않습니다.