시스템 단위 파일을 이해할 수 없습니다.
이것은 내 시나리오이며 다음과 같은 파일이 있습니다.내 서비스
내 서비스출시 후 어느 시점에 시작해야 하므로 다른 모든 것이 제자리에 있는 한 서두르지 마세요.
내 서비스Docker 컨테이너를 시작하므로 시작하고 싶습니다.도커.서비스시작하기 전에내 서비스(그것은 수도커.서비스내 시스템에서는 비활성화되어 있습니다).
언제든지도커.서비스그리고/또는 언제관리.서비스재부팅했습니다. 원합니다.내 서비스또한 다시 시작하십시오(docker 및 admin 이후).
내 서비스나중에 시작해야 함관리.서비스
이제 Requires=, After=, Wants= BindsTo= ReloadPropagatedFrom= 등이 너무 혼란스럽습니다. 이 조합을 사용해 왔지만 시작되지 않는 것 같습니다.도커.서비스...도 아니다내 서비스
[Unit]
Description=test
Requires=management.service
After=multi-user.target
Wants=docker.service management.service multi-user.target
BindsTo=docker.service management.service
ReloadPropagatedFrom=docker.service
[Service]
ExecStartPre=/usr/bin/start.sh
ExecStop=/usr/bin/stop.sh
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
내가 뭘 잘못했나요?
답변1
지침은 매뉴얼 페이지를 확인하십시오 systemd.unit. 아래에 포함되어 있지만 설명하기 위해 최선을 다하겠습니다.
Requires강한 의존성입니다. 활성화 되면 my.service다음에 나열된 항목 Requires=도 활성화됩니다. 나중에 나열된 장치 중 하나 Requires=가분명히멈추면 my.service멈추게 됩니다. 아니요 Before=또는 를 After=사용하여 순서 my.service와 나중에 나열된 단위를 설정하면 Requires=동시에 시작됩니다.
Wants약한 의존성이다. 시작되면 나중에 나열된 장치가 Wants=시작됩니다. my.service그러나 나열된 장치에 시동에 문제가 있는 경우 my.service시동이 중단되지 않습니다.
BindsToRequires보다 종속성이 더 강합니다. 이는 요구 사항과 유사하지만 어떤 이유로든 BindsTo=나열된 서비스 my.service도 중지된 후 중지됩니다.
After둘 Before다 순서를 지정하는 데 사용됩니다. 이는 Requires, Wants및 와는 별도의 설정 BindsTo이지만 서비스의 시작 순서를 지정하는 데 함께 사용할 수 있습니다.
PropagatesReloadToPropagatesReloadFrom여러 장치에 걸쳐 재로드를 대기열에 넣는 데 사용됩니다 . my.service지정하는 경우 PropagatesReloadTo=docker.service다시 로드 하면 my.service다시 로드됩니다 docker.service. my.service지정하는 경우 PropagatesReloadFrom=docker.service다시 로드 하면 docker.service다시 로드됩니다 my.service.
Wants가능한 경우 Requiresor 를 사용하는 것이 다소 권장됩니다 BindsTo.
Wants, Requires및 와 서비스를 중복하지 마십시오 BindsTo. 지정하려는 유닛 파일의 서비스 요구 사항에 적합한 것을 결정하고 사용하십시오.
docker.service 및/또는 Management.service가 다시 시작될 때마다 my.service도 다시 시작되기를 원합니다(docker 및 관리 이후).
다른 서비스가 다시 시작될 때 한 서비스를 다시 시작하려면 PartOf=대신 사용할 수 있습니다 Requires.
PartOf=는 Requires=와 유사하게 종속성을 구성하지만 장치를 중지하고 다시 시작하는 것으로 제한됩니다. systemd가 여기에 나열된 장치를 중지하거나 다시 시작하면 작업이 해당 장치에 전파됩니다. 이는 단방향 종속성입니다. 이 장치를 변경해도 나열된 장치에는 영향을 미치지 않습니다.
my.service는 docker 컨테이너를 시작하므로 my.service를 시작하기 전에 docker.service를 시작하고 싶습니다(docker.service는 내 시스템에서 비활성화될 수 있습니다).
After=docker.service management.service다음에 시작 하도록 설정 my.service하고 위에 나열된 대로 다시 시작하려면 을 사용하십시오. 다시 시작을 전파할 필요가 없으면 아마도 , 및 사이에서 결정하게 될 것입니다. 하지만 불필요하고 강력한 종속성을 만들지 않도록 노력하세요.docker.servicemanagement.servicePartOf=docker.service management.serviceWantsRequiresBindsTo
그 다음에
필요=
다른 단위에 대한 요구 사항 종속성을 구성합니다. 이 장치가 활성화되면 여기에 나열된 장치도 활성화됩니다. 다른 장치 중 하나가 활성화되지 않고 주문 종속성이 이후=인 경우
설정에 실패한 장치는 시작되지 않습니다. 또한 After= 지정 여부에 관계없이 다른 장치 중 하나가 명시적으로 중지되면 이 장치가 중지됩니다. 이 옵션은 여러 번 지정할 수 있습니다.
하나의 옵션에 여러 개의 공백으로 구분된 단위를 지정할 수 있으며, 이 경우 나열된 모든 이름에 대해 요구 사항 종속성이 생성됩니다. 요구사항 종속성은 서비스 순서에 영향을 주지 않습니다.
시작 또는 중지되었습니다. 이는 After= 또는 Before= 옵션을 사용하여 독립적으로 구성해야 합니다. foo.service 장치에 bar.service 장치가 필요하고 Requires=로 구성되었으며 순서가 구성되지 않은 경우
After= 또는 Before=, foo.service가 활성화되면 두 장치는 지연 없이 동시에 시작됩니다. 목표를 달성하려면 Requires= 대신 Wants=를 사용하는 것이 더 나은 경우가 많습니다.
실패한 서비스를 처리할 때 시스템이 더욱 강력해졌습니다.
이 종속성 유형은 이 장치가 실행 중일 때 다른 장치가 항상 활성화되어야 한다는 의미는 아닙니다. 구체적으로: 조건 확인 실패(예: ConditionPathExists=,
ConditionPathIsSymbolicLink=, ... — 아래 참조)은 Requires= 종속성이 있는 장치에 대한 시작 작업이 실패하도록 만들지 않습니다. 또한 일부 장치 유형은 자체적으로 비활성화될 수 있습니다(예: 서비스 프로세스에서
완전히 종료하거나 사용자가 장치를 분리했을 수 있음) Requires= 종속성이 있는 장치에는 전파되지 않습니다. 단위가 절대 나타나지 않도록 하려면 After=와 함께 BindsTo= 종속성 유형을 사용하십시오.
활성 상태, 특정 다른 장치도 활성 상태가 아닙니다(아래 참조).
원하다 =
Requires=의 약한 버전입니다. 하이브가 이미 시작된 경우 이 옵션에 나열된 장치가 시작됩니다. 그러나 나열된 장치를 시작할 수 없거나 거래에 추가할 수 없는 경우 이는 유효성에 영향을 미치지 않습니다.
전체 거래. 이는 한 장치의 시작을 다른 장치의 시작에 연결하는 권장 방법입니다.
= 전, = 후
두 설정 모두 공백으로 구분된 단위 이름 목록이 필요합니다. 하이브 간의 종속성을 주문합니다. 장치 foo.service에 Before=bar.service 설정이 포함되어 있고 두 장치가 모두 시작되는 경우,
foo.service 시작이 완료될 때까지 bar.service 시작이 지연됩니다. 이 설정은 Requires=, Wants= 또는 BindsTo=로 구성된 요구 사항 종속성과 독립적이며 직교합니다. 이것은
일반적인 패턴은 After= 및 Requires= 옵션에 장치 이름을 포함하는 것입니다. 이 경우 나열된 장치는 이러한 옵션으로 구성된 장치보다 먼저 시작됩니다. 이 옵션을 사용하면 더 많은 것을 지정할 수 있습니다
이 경우 나열된 모든 이름에 대해 정렬 종속성이 두 번 이상 생성됩니다. After=는 Before=의 역수입니다. 즉, After=는 나열된 장치의 시작이 완료된 후 구성된 장치가 시작되도록 보장합니다.
up, Before=는 그 반대를 보장합니다. 즉, 나열된 장치가 시작되기 전에 구성된 장치가 완전히 시작됩니다. 순차 종속성을 갖는 두 개의 유닛이 닫힐 때,
애플리케이션 시작 순서. 즉, 한 장치가 다른 장치에 After=를 구성한 경우 두 장치가 모두 종료되면 전자가 후자보다 먼저 중지됩니다. 두 유닛 사이에 순차적 종속성이 있는 경우, 유닛이 있는 경우
하나는 종료하는 것이고, 다른 하나는 먼저 종료한 다음 켜는 것입니다. 이 경우 순서 종속성이 After=인지 Before=인지는 중요하지 않습니다. 둘 중 어느 쪽이 닫혀 있는지는 중요하지 않습니다.
종료하려면 하나를 종료하고 다른 하나를 시작하면 됩니다. 모든 경우에 시작하기 전에 종료가 명령됩니다. 두 장치 사이에 순차적 종속성이 없으면 종료되거나 시작됩니다.
동시에 정렬이 발생하지 않습니다. 장치 부팅이 완료되는 시기는 장치 유형에 따라 다릅니다. 가장 중요한 것은 서비스 단위의 경우 시작이 완료된 것으로 간주된다는 것입니다.
이전=/이후= 구성된 모든 시작 명령이 호출되고 실패하거나 성공적인 시작을 보고한 경우.
=에 묶다
요구 사항 종속성을 구성합니다. 스타일은 Requires=와 매우 유사합니다. 그러나 이러한 유형의 종속성은 더 강력합니다. Requires=의 효과 외에도 바인딩된 유닛이 중지되면 해당 유닛은
또한 차단되었습니다. 즉, 갑자기 비활성화된 다른 장치에 바인딩된 장치도 중지됩니다. 다양한 이유로 인해 장치가 갑자기 예기치 않게 비활성화될 수 있습니다. 서비스의 주요 프로세스
장치는 자체적으로 종료될 수 있고, 장치를 지원하는 장치의 플러그가 뽑힐 수 있으며, 장치가 설치된 마운트 지점이 시스템 및 서비스 관리자의 개입 없이 마운트 해제될 수 있습니다.
BindsTo=의 동작은 동일한 셀에서 After=와 함께 사용될 때 더욱 강력해집니다. 이 경우 엄격하게 바인딩된 유닛이 활성화되어야 하며, 이 유닛도 활성화됩니다. 이것은 아니다
이는 다른 장치에 바인딩된 장치가 갑자기 비활성화되었음을 의미할 뿐 아니라 조건 확인 실패로 인해 다른 장치에 바인딩된 장치를 건너뛰었음을 의미합니다(예: ConditionPathExists=,
ConditionPathIsSymbolicLink=, ... — 아래 참조)이 실행되면 중지됩니다. 따라서 많은 경우 BindsTo=와 After=를 결합하는 것이 더 좋습니다.
PropagatesReloadTo=, ReloadPropagatedFrom=
장치에 대한 재로드 요청이 전파되거나 다른 장치에 대한 재로드 요청이 전파될 하나 이상의 장치를 공백으로 구분한 목록입니다. 새로고침 요청하기
또한 장치는 자동으로 재로드 요청을 모든 장치에 대기열에 추가하며, 재로드 요청은 두 설정을 통해 전파됩니다.