☰

추가 읽기

tag-icon • tag-icon linux systemd fork
추가 읽기

내 nginx 단위 파일은 다음과 같습니다.

[root@arif ~]# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
# Nginx will fail to start if /run/nginx.pid already exists but has the wrong
# SELinux context. This might happen when running `nginx -t` from the cmdline.
# https://bugzilla.redhat.com/show_bug.cgi?id=1268621
ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=process
PrivateTmp=true

[Install]
WantedBy=multi-user.target

여기 이 [Service]섹션에서 의 값은 다음 Type과 같습니다.forking여기,

ExecStart로 시작된 프로세스는 서비스의 기본 프로세스가 되는 하위 프로세스를 생성합니다. 시작이 완료된 후 상위 프로세스가 종료됩니다.

내 질문은,

  • 서비스가 왜 이런 일을 하는가?
  • 이렇게 하면 어떤 이점이 있나요?
  • Type=simple아니면 다른 유사한 옵션에는 어떤 문제가 있습니까?

답변1

서비스가 왜 이런 일을 하는가?

평균 서비스원하지 않는다실제로 그렇게 하세요. 이것이 좋은 습관이 아니며 "데몬"에 대한 생각이 실제로 잘못되었다는 사실 외에 서비스가 또 무엇을 할 수 있습니까?forking계약에 의해 요구되지 않음. 그들이 실제로 하고 있던 일 때문에 프로토콜이 잘못되었습니다.다른 것, 이는 forking프로토콜에 포함되어 있으며 일반적으로 불필요합니다.

이렇게 하면 어떤 이점이 있나요?

아니요. 더 나은 대비 알림 프로토콜이 존재하지만 실제로 말하는 사람은 없습니다.이것프로토콜이 정확합니다. 그렇게 하는 것이 유리하기 때문에 서비스는 이렇게 하지 않습니다.

Type=simple아니면 다른 유사한 옵션에는 어떤 문제가 있습니까?

아무것도 없습니다. 실제로 일반적으로 말하면 준비 프로토콜은 forking잘못 사용됩니다. 다른 답변에서 언급했듯이 이는 모범 사례가 아닙니다. 정반대.

단순한 사실은 그것이 나쁜 일의 최선이자 nginx의 여전히 막을 수 없는 행동으로부터의 피난처라는 것입니다. 오늘날 IBM SRC, daemontools 및 기타 심각한 서비스 관리 분야의 격려 덕분에 대부분의 서비스 소프트웨어에는 옵션이 제공되었으며 심지어 기본 동작도 변경되어 더 이상 어리석게 무언가를 "데몬화"하려고 시도하지 않습니다.이미 데몬 컨텍스트에 있음.

그러나 nginx의 경우에는 여전히 그렇지 않습니다. daemon off안타깝게도 작동하지 않습니다. 많은 소프트웨어가 "비데몬" 모드를 디버그 모드와 실수로 혼동한 것처럼(그러나 일반적으로 더 이상 그렇게 하지 않음) nginx는 불행하게도 제어 신호를 처리하지 않는 등의 다른 것과 혼동합니다. 지금까지 사람들은 이 일을 5년 동안 해왔습니다.

추가 읽기

답변2

systemd가 초기화를 완료한 후 관련 서비스가 메시징을 구체적으로 지원하지 않는 한(참고자료 참조 man systemd-notify) 포크 방법은 전통적인 알림 방법으로 사용됩니다. systemd에 의해 보고된 서비스 상태는 상위 프로세스가 존재하는 한 systemctl status유지됩니다 start. 상위 프로세스가 종료된 후에 만
으로 변경됩니다 . running기존 데몬 서비스의 상위 프로세스는 하위 프로세스가 설정을 완료하고 사용할 준비가 된 후에만 종료됩니다.

관련 서비스를 사용할 준비가 되기를 기다리는 종속 서비스가 있는 경우 이 메커니즘이 필요합니다. 특정 알림 방법을 지원하지 않는 서비스를 시작하기 위해 기존 데몬 분기 메커니즘을 사용하지 않는 경우 systemd서비스 상태는 running즉시로 변경되고 관련 서비스를 사용할 준비가 되기 전에 모든 종속 서비스가 즉시 시작됩니다.

이 이유는 에서 더 자세히 설명됩니다.데비안 버그 #728015이것은 이미 JdeBP의 답변에 연결되어 있습니다.
이 이유는 버그가 닫힌 이유이기도 합니다 wontfix.

관련 정보