서비스가 fork시스템 호출을 할 수 있도록 허용합니다. Systemd는 이를 차단하지 않으며 차단해도 이를 인지하지 않습니다. 이 문장은 특히 데몬 프로세스를 상위 프로세스로부터 분리하기 위해 데몬 프로세스 시작 부분에서 분기하는 관행을 나타냅니다. "프로세스는 [하위 프로세스에서 서비스가 실행되는 동안 상위 프로세스를 종료하고] 분기해서는 안 됩니다."

이것매뉴얼 페이지이에 대해서는 더 자세히 설명하고 이러한 특별한 혼란을 일으키지 않는 표현으로 설명합니다.

데몬으로 사용되는 많은 프로그램에는 시작 시 상위 프로세스로부터 자신을 격리하는 모드(일반적으로 기본 모드)가 있습니다. 데몬이 시작되고 호출된 fork()다음 상위 프로세스가 종료됩니다. 하위 프로세스는 이를 호출하여 setsid()자체 프로세스 그룹 및 세션에서 실행하고 서비스를 실행합니다. 그 목적은 쉘 명령줄에서 데몬을 호출하는 경우 터미널에 어떤 일이 발생하더라도(예: 터미널 닫기) 데몬이 커널이나 쉘로부터 어떤 신호도 수신하지 않는다는 것입니다(이 경우 쉘은 모든 프로세스 그룹을 알고 있는 터미널에 SIGHUP을 보냅니다. 이로 인해 서비스 프로세스가 init에 의해 채택되어 종료 시 이를 수집하여 다음을 방지합니다.좀비데몬이 부적절한 것에 의해 시작된 경우 wait()(데몬이 쉘에 의해 시작된 경우에는 이런 일이 발생하지 않습니다).

systemd와 같은 모니터링 프로세스에 의해 데몬이 시작될 때 포크는 비생산적입니다. 서비스가 충돌하는 경우 모니터링 프로세스는 서비스를 다시 시작해야 하므로 서비스가 종료되었는지 알아야 합니다. 서비스가 모니터링 프로세스의 직접적인 하위 항목이 아닌 경우 이는 어렵습니다. 모니터링 프로세스가 영원히 사라져서는 안 되며, 제어하는 ​​단말이 없기 때문에 원치 않는 신호나 하베스팅에 대해 걱정할 필요가 없습니다. 따라서 서비스 프로세스가 모니터의 하위 프로세스가 되지 않을 이유가 없으며 그렇게 하는 데에는 충분한 이유가 있습니다.

이 Arch 위키 페이지를 무시하세요.

설정에 꽤 큰 버그가 있습니다 Type. 그리고 그것은 설명에만 국한되지 않습니다 simple. 말하는 내용 forking도 틀렸습니다.

이런 종류의 일에 대한 좋은 조언은 수십 년 동안 존재해 왔으며 systemd 자체보다 오래되었으며 적어도 1990년대 초반으로 거슬러 올라갑니다. 내가 그랬던 것처럼https://unix.stackexchange.com/a/476608/5132, systemd doco의 최신 버전에 대한 Johnny의 데몬 제안이 있는데, 이는 daemontools 사용자, IBM, 를 사용하는 사람들 inittab, 그리고... 음... 제가 수십 년 동안 말해왔던 내용을 대부분 반복합니다. (2001년 제가 이 질문을 썼을 당시에는 이미 자주 나오는 답변이었습니다.)

반복하다:

프로그램에 일종의 "데몬" 메커니즘이 있는 경우, 특히 하위 프로세스를 포크하고 상위 프로세스를 종료하는 경우,꺼 줘그리고사용하지 마세요. daemontools 등에게 감사드립니다. 이것이 오랫동안 요구되었던 부분에서는 많은 프로그램이 다음 기능을 향상시켰습니다.아니요이러한 메커니즘은 지난 20년 이상 동안 존재해 왔지만 다른 메커니즘은 애초에 "데몬"으로 기본 설정되지 않았으므로 기본 작동 모드에서 사용할 수 있었습니다.

서비스 관리 하위 시스템이 서비스 프로세스를 시작합니다.이미 데몬 컨텍스트에 있음. 이러한 프로세스에는 "데몬"이 필요하지 않습니다. (실제로 많은 최신 운영 체제에서 프로그램은 심지어할 수 있는로그인 세션 컨텍스트에서 "dæmonize"는 "dæmonization"이 실제로 의미하는 것입니다. ) 그들은 이미 데몬 컨텍스트에 적합한 환경 값과 열린 파일 설명자를 가지고 있으며 실제로 "데몬화"가 수행하는 몇 가지 작업이 있습니다.막다서비스 관리자는 정기적으로 데몬을 사용하여 몇 가지 일반적인 작업(예: 표준 출력/오류를 로그에 캡처)을 수행합니다.

을 선호하고 Type=simple, 미리 소켓을 엽니다(서비스 관리자가 서버 소켓을 열고 이를 열린 파일 설명자로 서비스 프로그램에 전달합니다) Type=notify.

• Type=simple서비스 프로세스가 시작되자마자 서비스는 준비된 것으로 간주되며(주문된 서비스가 시작/중지될 수 있도록) 클라이언트 서비스를 연기하기 위해 클라이언트가 서버에 연결을 시도하는 동안 가능한 한 빨리 소켓이 열립니다. . 서버가 실제로 준비될 때까지 서비스를 제공합니다.
• Type=notifysystemd 및 Linux에 특정한 단점이 있습니다(쉘 생성과 같은 단기 프로세스에서 기능할 수 없음 systemd-notify, 파서 문제가 있는 권한 있는 프로세스에서 사람이 읽을 수 있는 형식을 기계가 읽을 수 있는 형식으로 구문 분석하는 문제 포함).그것이 일어났다과거), 그러나 서비스가 실제로 준비된 것으로 간주되는 시점에 대해 (서비스 프로그램의 관점에서) 더 세부적인 제어를 제공한다는 장점이 있습니다. 또한 상태 출력을 일부 사용자 정의할 수도 있습니다.

두 가지 유형의 서비스 프로그램 모두 분기될 수 있습니다. 그것은 포크이다그런 다음 원래 프로세스를 종료하십시오.그것이 문제이다.

(쉘에서 프로그램을 실행하는 것은 서비스 관리자에서 프로그램을 실행하는 것만큼 문제가 있다는 점에 유의해야 합니다. 사용자는 프로그램이 종료되는 것을 보고 거의 즉시 다른 쉘 프롬프트로 연결됩니다. 실제로 오늘 누군가가 다시 물었습니다. 쉘에서 부모를 분기하고 종료하는 프로그램을 실행합니다.가끔 터미널에서 프로그램을 실행할 때 터미널에서 실행되지 않는 이유는 무엇입니까?.)

Type=oneshot이 특별한 경우에는 전체 서비스 프로그램이 실행되어 완료될 때만 서비스가 준비된 것으로 간주되므로 원하는 것이 아닐 수도 있습니다. 용도가 있지만 귀하에게 적용되는 것 같지는 않습니다.

사용하지 마십시오 Type=forking. 절차가 거의 없으므로 최후의 수단이 되어야 합니다.사실 합의는. 그들은 안에 있다다른 것, 이는 실제로아니요이 프로토콜은 이 프로토콜과 올바르게 상호 운용되지 않으며 실제로 준비 상태를 알리지 않습니다.

추가 읽기

• 조나단 드보인 폴라드(2001). Unix 데몬을 설계할 때 피해야 할 실수. 일반적인 답변.
• 조나단 데보인 폴라드(2015).실제로 데몬이 필요하지 않습니다. 진짜.. 체계화된 공포의 집.
• 조나단 데보인 폴라드(2015).Unix 데몬의 준비 프로토콜 문제. 자주 주어지는 답변입니다.
• https://unix.stackexchange.com/a/401611/5132