☰

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

tag-icon • tag-icon systemd fork
이 Arch 위키 페이지를 무시하세요.

나는 매우 오랫동안 실행되는 명령 1 (몇 시간 단위) systemd을 관리하기 위해 나만의 유닛 파일을 작성하고 싶습니다 . 보는 동안systemd에 대한 ArchWiki 기사, 시작 유형 선택과 관련하여 다음과 같이 말합니다.

Type=simple(기본값): systemd는 서비스가 즉시 시작되는 것으로 간주합니다.프로세스가 분기되어서는 안 됩니다.. 소켓이 활성화되지 않은 한 이 서비스에 대해 다른 서비스를 주문해야 하는 경우 이 유형을 사용하지 마십시오.

프로세스가 전혀 포크되지 않아야 하는 이유는 무엇입니까? 데몬 소환 프로세스(상위 포크 후 종료) 스타일의 포크를 말하는 건가요, 아니면 어떤 종류의 포크인가요?

1 tmux/screen을 사용하지 않고 상태를 확인하고 서비스를 다시 시작하는 보다 우아한 방법을 원하기 때문에 tmux/screen을 원하지 않습니다 tmux send-keys.

답변1

서비스는 fork시스템 호출을 호출할 수 있습니다. Systemd는 이를 방지하지 않으며 방지할 경우에도 이를 인지하지 않습니다. 이 문장은 데몬을 상위 프로세스로부터 분리하기 위해 데몬 시작 부분에서 분기하는 관행을 구체적으로 언급하고 있습니다. "프로세스는 [자식 프로세스에서 서비스를 실행하는 동안 상위 프로세스를 종료하고] 분기해서는 안 됩니다."

그만큼매뉴얼 페이지이 특별한 혼란을 초래하지 않는 표현으로 이것을 더 장황하게 설명합니다.

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

systemd와 같은 모니터링 프로세스에 의해 데몬이 시작되면 포크는 역효과를 낳습니다. 모니터링 프로세스는 서비스가 충돌할 경우 서비스를 다시 시작하도록 되어 있으므로 서비스가 종료되는지 알아야 하며, 서비스가 모니터링 프로세스의 직접적인 하위 항목이 아닌 경우에는 어렵습니다. 모니터링 프로세스는 종료되지 않으며 제어 터미널이 없으므로 원치 않는 신호나 수확에 대한 우려가 없습니다. 따라서 서비스 프로세스가 모니터의 하위 프로세스가 되지 않을 이유가 없으며 그럴 만한 이유가 있습니다.

답변2

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

설정 과 관련하여 상황이 상당히 잘못되었습니다 Type. 게다가 이는 에 대한 설명에만 국한되지 않습니다 simple. 그것에 대해 말하는 것도 forking잘못되었습니다.

이런 종류의 것에 대한 올바른 권장 사항은 systemd 자체가 존재했던 것보다 수십 년 동안 존재해 왔으며 적어도 1990년대 초반으로 거슬러 올라갑니다. 내가 언급했듯이https://unix.stackexchange.com/a/476608/5132inittab, systemd doco에는 daemontools 사용자, IBM, 를 사용하는 사람들 , 그리고 ...음... 제가 수십 년 동안 말해왔던 내용을 크게 반복하는 데몬에 대한 권장 사항의 최신 버전이 있습니다 . (2001년 제가 글을 쓸 당시에도 이미 자주 나오던 답변이었습니다.)

반복하려면:

프로그램에 특히 하위 프로세스를 포크하고 상위 프로세스를 종료하는 "데몬화" 메커니즘이 있는 경우,꺼 줘그리고그것을 사용하지 마십시오. daemontools 등에게 감사드립니다. 이것이 오랫동안 요구되었던 곳에서는 많은 프로그램이 다음을 수행할 수 있는 능력을 키워왔습니다.가지고 있지 않다이러한 메커니즘은 지난 20년 이상 동안 사용되었으며 다른 메커니즘은 애초에 "데몬화"를 기본으로 하지 않으므로 기본 작동 모드에서 사용할 수 있습니다.

서비스 관리 하위 시스템이 서비스 프로세스를 시작합니다.이미 데몬 컨텍스트에서. 이러한 프로세스는 "데몬화"할 필요가 없습니다. (사실, 많은 현대 운영 체제에서는 프로그램이~할 수 있다실제로 "dæmonization"이 무엇인지에 대한 것인 로그인 세션 컨텍스트에서 "dæmonize"를 수행합니다.) 이미 환경 값이 있고 데몬 컨텍스트에 적합한 열린 파일 설명자와 실제로 "dæmonization"이 수행하는 여러 작업이 있습니다.방해하다서비스 관리자가 데몬을 사용하여 정기적으로 수행하는 일부 기존 작업(예: 표준 출력/오류를 로그에 캡처).

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

  • Type=simple서비스 프로세스가 시작되자마자 서비스를 준비된 것으로 처리합니다(주문된 서비스가 시작/중지될 수 있도록). 서비스 클라이언트가 서버에 연결을 시도하는 지점에서 서비스 클라이언트를 지연시키기 위해 소켓 연결 의미론을 사용하는 조기 소켓 열기를 사용합니다. 서버가 실제로 준비될 때까지 서비스를 제공합니다.
  • Type=notifysystemd 및 Linux 특유의 단점이 있습니다(셸 생성과 같은 단기 프로세스에서 작동하지 않는다는 문제 systemd-notify와 함께 권한 있는 프로세스에서 사람이 읽을 수 있는 형식을 기계가 읽을 수 있는 형식으로 구문 분석하는 문제도 있습니다. 파서 문제가 있습니다이미 일어난 일과거에는) 서비스가 실제로 준비된 것으로 간주되는 시기를 (서비스 프로그램의 관점에서) 더 세밀하게 제어할 수 있다는 장점이 있습니다. 또한 상태 출력을 일부 사용자 정의할 수도 있습니다.

두 가지 유형의 서비스 프로그램 모두 분기할 수 있습니다. 포킹이다그런 다음 원래 프로세스를 종료합니다.그게 문제 야.

(이것은 서비스 관리자에서 프로그램을 실행하는 것과 마찬가지로 셸에서 프로그램을 실행하는 데에도 문제가 된다는 점에 유의해야 합니다. 사용자는 프로그램이 종료되고 거의 즉시 다른 셸 프롬프트가 표시되는 것을 볼 수 있습니다. 실제로 오늘 누군가가 다시 묻고 있었습니다. , 부모를 분기하고 종료하는 셸에서 프로그램을 실행하는 방법에 대한 내용은 다음과 같습니다.가끔 터미널에서 프로그램을 실행할 때 터미널에서 실행되지 않는 이유는 무엇입니까?.)

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

절대 사용하지 마십시오 Type=forking. 프로그램이 거의 없기 때문에 최후의 수단이 되어야 한다.실제로 프로토콜을 말해보세요. 그들은하고있어다른 것, 이는 실제로~ 아니다이 프로토콜은 이 프로토콜과 올바르게 상호 운용되지 않으며 실제로 준비 상태를 신호하지 않습니다.

추가 읽기

관련 정보