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