일부 프로그램에는 php-fpm과 같이 백그라운드에서 실행되는 --daemonize 옵션이 있습니다. --daemonize를 사용하는 것과 백그라운드에서 프로세스를 실행하는 기존 방식을 사용하는 것 사이에 차이점이 있는지 궁금합니다.
나는 그렇지 않으면 왜 --daemonize를 제공해야 하는지, 왜 &를 사용하여 실행하지 않는지 생각합니다.
하지만 이에 대한 정보를 찾을 수 없습니다. 예를 들어, 저는 php-fpm &으로 php-fpm --daemonize를 테스트하고 몇 가지 제한된 테스트를 수행했습니다. 나는 어떤 차이도 볼 수 없습니다.
- - - 갱신 - - -
Dockerfile CMD 셸을 exec 형식으로 사용하려고 할 때 이 문제가 다시 발생했습니다.
어쩌면 여기에 SO 토론을 추가하는 것이 가치가 있을 것입니다.https://stackoverflow.com/questions/42805750/dockerfile-cmd-shell-versus-exec-form
답변1
&쉘 구문은 다음과 같습니다. 쉘은 백그라운드에서 프로그램을 시작한 다음 이를 모니터링합니다(예를 들어, wait백그라운드 프로세스를 사용하고 완료될 때까지 기다릴 수 있습니다). 따라서 이를 작동시키려면 쉘을 사용해야 하지만 모든 경우에 이것이 바람직하지 않거나 가능하지는 않습니다.
--daemonize비슷한 옵션은 프로그램 자체에서 처리됩니다.이중 십자가 및 setid시작된 모든 것에서 스스로 분리되므로 프로그램을 시작하는 다른 방법(예: C의 분기 및 실행)과 함께 작동합니다.
어떤 것을 사용하고 싶은지는 프로그램 시작 방법과 나중에 프로그램을 어떤 상태로 만들 것인지에 따라 달라질 수 있습니다.
특이한 예를 들어보세요 sudo. sudo백그라운드에서 명령을 실행하고 싶지만 인증이 필요한 경우 실행 시 비밀번호를 제공할 수 없습니다 sudo foo bar &. 물론 한 가지 접근 방식은 먼저 아무 작업도 수행하지 않거나 인증을 수행하지 않는 명령을 사용한 -v다음 sudo 시간 초과를 사용하여 &두 번째로 비밀번호를 입력할 필요 없이 실제 명령을 실행하는 것입니다. 또 다른 방법은 포그라운드에서 실행한 다음 및 를 CtrlZ사용하여 백그라운드로 보내는 것입니다 bg. 그러나 포그라운드에서 실행하고 비밀번호를 요청한 다음 데몬화하는 옵션이 sudo있습니다 (그러나 이 경우 셸의 작업 제어를 사용할 수 없습니다).--background
다른 부작용도 있습니다. 예를 들어, &bash를 사용하여 백그라운드에서 프로그램을 실행할 때 작업 제어가 활성화되지 않은 경우(스크립트의 기본값) /dev/null새 프로세스의 표준 입력은 로 설정됩니다. 와 같은 옵션을 사용하면 --daemonize프로그램은 상속받은 표준 입력을 처리하는 방법을 결정할 수 있습니다.