내가 문서에서 알 수 있는 한체계화된, 전자가 종속 유닛 파일에 저장되고 그 반대의 경우도 제외된다는 점을 제외 Wants=
하면 WantedBy=
동일한 기능을 수행합니다. (그리고 디렉토리를 WantedBy=
생성 unit.type.wants
하고 심볼릭 링크로 채웁니다.)
에서DigitalOcean: 시스템 단위 및 단위 파일 이해:
지시문 ...을 사용하면 섹션 의 지시문
WantedBy=
과 유사한 방식으로 종속 관계를 지정할 수 있습니다 . 차이점은 이 지침이 보조 장치에 포함되어 나열된 기본 장치가 상대적으로 깨끗한 상태를 유지할 수 있다는 것입니다.Wants=
[Unit]
정말로 유닛 파일을 "깨끗하게" 유지하는 것이 목적인가요? 이 두 지시문을 사용하는 가장 좋은 방법은 무엇입니까? 즉, 서비스 알파가 서비스 베타를 "원하는" 경우 언제 를 사용해야 하며 Wants=beta.service
언제 를 alpha.service
선호해야 합니까 ? WantedBy=alpha.service
beta.service
답변1
기능적으로
Wants
Unit
는 섹션 에 있고 WantedBy
는 에 있습니다 Install
.
init 프로세스는 해당 섹션을 전혀 systemd
처리/사용하지 않습니다 . Install
대신에 심볼릭 링크를 생성해야 합니다 multi-user.target.wants
. 일반적으로 이는 systemctl
해당 섹션을 읽는 유틸리티에 의해 수행됩니다 Install
.
요약하자면,WantedBy
systemctl enable
/ 의 영향을 받습니다 systemctl disable
.
논리적으로
어떤 서비스가 다른 서비스를 "알고" 있어야 하는지, 아니면 "인식"해야 하는지 고려하세요. 예를 들어 다음과 같은 일반적인 용도는 다음과 같습니다 WantedBy
.
[Install]
WantedBy=multi-user.target
또는 multi-user.target에 있을 수도 있습니다.
[Unit]
Wants=nginx.service
그러나 두 번째 방법은 의미가 없습니다. 논리적으로 nginx.service는 시스템 정의 multi-user.target에 대해 알고 있지만 그 반대는 아닙니다.
따라서 귀하의 예에서 알파의 작성자가 베타를 알고 있다면 알파 Wants
베타입니다. 베타 작성자가 알파를 알고 있다면 베타는 WantedBy
알파입니다.
결정하는 데 도움이 되도록 다른 서비스 없이 설치할 수 있는 서비스(예: 패키지 관리자에서)를 고려할 수 있습니다.
구성 디렉토리
상자에 있는 또 다른 도구로서 systemd 파일은 구성 디렉터리(/etc/systemd/system/myservice.service.d/extension.conf)를 사용하여 확장될 수도 있다는 것을 알아두십시오.
이를 통해 두 서비스 모두 원래 다른 서비스에 대해 알 수 있도록 작성되지 않은 종속성을 추가할 수 있습니다. 나는 종종 이것을 마운트와 함께 사용하는데, 예를 들어 nginx나 마운트 모두 다른 것에 대한 명시적인 지식이 필요하지 않지만 시스템 관리자로서 나는 종속성을 이해합니다. nginx.service.d/mymount.conf
그래서 나는 Wants=mnt-my.mount
.
답변2
이는 기능적으로 동일하지 않습니다. 설정 Wants=
(및 기호 링크 파일)은 종속성입니다. 이 WantedBy=
설정은 서비스가 활성화/비활성화될 때 이러한 종속성의 생성/파괴를 제어합니다.
그래서 없어요최상의관행. 있다옳은관행. 주어진 상황에 대해 둘 중 하나만 올바른 기능을 갖습니다. 항상 존재하는 지속적인 종속성을 가지려고 하거나 enable
/ 를 사용하여 켜고 끌 수 있는 일시적인 종속성을 가지려는 경우가 있습니다 disable
.