나는 데몬 프로세스를 생성하는 방법을 읽고 이해했지만, 내가 읽은 모든 것 중에서는 전혀 이해하지 못했습니다.왜그것은 완료되어야합니다.
터미널 제어권을 얻기 위한 프로세스를 피하기 위해 fork -setsid -fork를 수행한다는 내용을 읽었는데 이것이 무엇을 의미합니까? &(예: './script &' )를 사용하여 백그라운드에서 프로그램을 시작하는 경우 이 프로세스의 실행이 자신을 데몬으로 전환하는 프로그램을 정상적으로 실행하는 경우와 어떻게 다릅니까?
이는 단순히 로그아웃하면 백그라운드 프로세스가 중지되고 데몬이 계속 실행된다는 의미입니까? 나는 '터미널 제어권 확보'를 이해하는 데 정말로 어려움을 겪고 있습니다.
이것이 나를 괴롭히는 이유는 내가 로봇에 임베디드 RPi를 작업하고 있기 때문에 부팅 시 프로그램이 시작되도록 해야 하기 때문입니다. 현재는 다음과 같은 명령을 사용하여 rc.local에서 시작하고 있습니다 su user -c 'python /home/user/launcher.py &' &
. 부팅 시 프로그램이 시작되는 데 아무런 문제가 발생한 적이 없지만( ps -e
RPi에 SSH로 연결할 때 사용하는 프로세스도 볼 수 있습니다) 위험이 있는지/나쁜 습관인지 알고 싶습니다.
답변1
이는 하나 이상의 질문이며 각 질문에는 긴 답변이 있을 수 있습니다. 간단히
&(예: './script &' )를 사용하여 백그라운드에서 프로그램을 시작하는 경우 이 프로세스의 실행이 자신을 데몬으로 전환하는 프로그램을 정상적으로 실행하는 경우와 어떻게 다릅니까?
백그라운드에서 프로그램을 실행하면 더 이상 터미널에서 직접 제어할 수 없지만(단순히
^C
제어할 수는 없음) 여전히 터미널에 쓰고 작업을 방해할 수 있습니다. 일반적으로 데몬은 터미널에서 자체적으로 분리되며(포킹 외에도) 해당 출력/오류는 파일로 리디렉션됩니다.이는 단순히 로그아웃하면 백그라운드 프로세스가 중지되고 데몬이 계속 실행된다는 의미입니까?
백그라운드 프로세스는 보호될 수 있지만
nohup
출력이 리디렉션되지 않는 한 터미널을 닫으면 쓰기가 방지되고 중지될 수 있는 오류가 발생합니다.위험이 있는지/나쁜 습관인지 알고 싶습니다.
프로그램의 출력(및 오류 메시지)을 추적하는 문제 외에도 프로그램이 종료되면 다시 시작해야 하는 문제도 있습니다. 서비스 스크립트는 시스템의 다른 서비스가 설계된 방식에 적합하여 데몬을 제어하는 다소 표준적인 방법을 제공합니다.