웹사이트 검색

시스템 단위 및 단위 파일 이해

소개

점점 더 많은 Linux 배포판이 systemd 초기 시스템을 채택하고 있습니다. 이 강력한 소프트웨어 제품군은 서비스에서 마운트된 장치 및 시스템 상태에 이르기까지 서버의 여러 측면을 관리할 수 있습니다.

systemd에서 단위는 시스템이 작동하고 관리하는 방법을 알고 있는 모든 리소스를 나타냅니다. 이것은 systemd 도구가 처리하는 방법을 알고 있는 기본 객체입니다. 이러한 리소스는 단위 파일이라는 구성 파일을 사용하여 정의됩니다.

이 가이드에서는 systemd가 처리할 수 있는 다양한 단위를 소개합니다. 또한 이러한 리소스가 시스템에서 처리되는 방식을 형성하기 위해 유닛 파일에서 사용할 수 있는 많은 지시어 중 일부를 다룰 것입니다.

Systemd Unit은 무엇을 제공합니까?

단위는 systemd가 관리 방법을 알고 있는 개체입니다. 이들은 기본적으로 데몬 제품군에 의해 관리되고 제공된 유틸리티에 의해 조작될 수 있는 시스템 리소스의 표준화된 표현입니다.

단위는 다른 init 시스템의 서비스나 작업과 유사하다고 할 수 있습니다. 그러나 단위는 서비스, 네트워크 리소스, 장치, 파일 시스템 마운트 및 격리된 리소스 풀을 추상화하는 데 사용할 수 있으므로 훨씬 더 광범위한 정의를 가집니다.

다른 init 시스템에서 하나의 통합 서비스 정의로 처리할 수 있는 아이디어는 초점에 따라 구성 요소 단위로 나눌 수 있습니다. 이는 기능별로 구성되며 장치의 핵심 동작을 수정하지 않고도 기능을 쉽게 활성화, 비활성화 또는 확장할 수 있습니다.

유닛이 쉽게 구현할 수 있는 일부 기능은 다음과 같습니다.

  • 소켓 기반 활성화: 서비스와 관련된 소켓은 별도로 처리하기 위해 데몬 자체에서 분리하는 것이 가장 좋습니다. 이는 연관된 소켓이 처음 액세스될 때까지 서비스 시작을 지연시키는 것과 같은 많은 이점을 제공합니다. 이것은 또한 시스템이 부팅 프로세스 초기에 모든 소켓을 생성할 수 있도록 하여 관련 서비스를 병렬로 부팅할 수 있도록 합니다.
  • 버스 기반 활성화: 장치는 D-Bus에서 제공하는 버스 인터페이스에서도 활성화할 수 있습니다. 연결된 버스가 게시되면 장치를 시작할 수 있습니다.
  • 경로 기반 활성화: 특정 파일 시스템 경로의 가용성 또는 활동에 따라 장치를 시작할 수 있습니다. 이것은 inotify를 활용합니다.
  • 장치 기반 활성화: 장치는 udev 이벤트를 활용하여 관련 하드웨어의 첫 가용성에서 시작할 수도 있습니다.
  • 암시적 종속성 매핑: 유닛에 대한 대부분의 종속성 트리는 systemd 자체에 의해 구축될 수 있습니다. 여전히 종속성 및 주문 정보를 추가할 수 있지만 대부분의 어려운 작업은 자동으로 처리됩니다.
  • 인스턴스 및 템플릿: 템플릿 단위 파일을 사용하여 동일한 일반 단위의 여러 인스턴스를 만들 수 있습니다. 이것은 모두 동일한 일반 기능을 제공하는 약간의 변형 또는 형제 단위를 허용합니다.
  • 손쉬운 보안 강화: 유닛은 간단한 지시문을 추가하여 상당히 우수한 보안 기능을 구현할 수 있습니다. 예를 들어 파일 시스템의 일부에 대한 액세스 권한이 없거나 읽기 전용으로 지정하고, 커널 기능을 제한하고, 개인 /tmp 및 네트워크 액세스를 할당할 수 있습니다.
  • 드롭인 및 스니펫: 시스템 유닛 파일의 일부를 재정의하는 스니펫을 제공하여 유닛을 쉽게 확장할 수 있습니다. 이렇게 하면 기본 단위 구현과 맞춤 단위 구현 간에 쉽게 전환할 수 있습니다.

다른 init 시스템의 작업 항목에 비해 systemd 단위에는 다른 많은 이점이 있지만 기본 구성 지시문을 사용하여 활용할 수 있는 기능에 대한 아이디어를 제공해야 합니다.

Systemd Unit 파일은 어디에 있습니까?

systemd가 단위를 처리하는 방법을 정의하는 파일은 여러 위치에서 찾을 수 있으며 각 위치에는 서로 다른 우선 순위와 의미가 있습니다.

시스템의 유닛 파일 사본은 일반적으로 /lib/systemd/system 디렉토리에 보관됩니다. 소프트웨어가 시스템에 유닛 파일을 설치할 때 기본적으로 이 위치에 배치됩니다.

여기에 저장된 단위 파일은 세션 중에 필요에 따라 시작 및 중지할 수 있습니다. 이것은 표준 구현에서 systemd를 배포하는 모든 시스템에서 작동해야 하는 업스트림 프로젝트의 유지 관리자가 자주 작성하는 일반 바닐라 단위 파일입니다. 이 디렉터리의 파일을 편집하면 안 됩니다. 대신 필요한 경우 이 위치의 파일을 대체할 다른 단위 파일 위치를 사용하여 파일을 재정의해야 합니다.

장치가 작동하는 방식을 수정하려는 경우 가장 좋은 위치는 /etc/systemd/system 디렉토리입니다. 이 디렉토리 위치에 있는 단위 파일은 파일 시스템의 다른 위치보다 우선합니다. 시스템의 단위 파일 복사본을 수정해야 하는 경우 이 디렉터리에 대체 항목을 두는 것이 가장 안전하고 유연한 방법입니다.

시스템 유닛 파일의 특정 지시어만 재정의하려는 경우 실제로 하위 디렉토리 내에 유닛 파일 스니펫을 제공할 수 있습니다. 변경하려는 옵션만 지정할 수 있도록 시스템 복사본의 지시문을 추가하거나 수정합니다.

이를 수행하는 올바른 방법은 끝에 추가된 .d가 있는 유닛 파일의 이름을 딴 디렉토리를 만드는 것입니다. 따라서 example.service라는 단위에 대해 example.service.d라는 하위 디렉토리를 만들 수 있습니다. 이 디렉토리 내에서 .conf로 끝나는 파일을 사용하여 시스템 단위 파일의 속성을 재정의하거나 확장할 수 있습니다.

/run/systemd/system에는 런타임 단위 정의 위치도 있습니다. 이 디렉터리에 있는 유닛 파일은 /etc/systemd/system과 /lib/systemd/system에 있는 파일 사이에 우선 순위가 있습니다. 이 위치에 있는 파일에는 이전 위치보다 가중치가 적지만 후자보다 가중치가 높습니다.

systemd 프로세스 자체는 런타임에 생성된 동적으로 생성된 단위 파일에 대해 이 위치를 사용합니다. 이 디렉토리는 세션 기간 동안 시스템의 장치 동작을 변경하는 데 사용할 수 있습니다. 서버가 재부팅되면 이 디렉터리에서 변경한 모든 내용이 손실됩니다.

단위의 종류

Systemd는 설명하는 리소스 유형에 따라 단위를 분류합니다. 단위 유형을 결정하는 가장 쉬운 방법은 리소스 이름 끝에 추가되는 유형 접미사를 사용하는 것입니다. 다음 목록은 systemd에서 사용할 수 있는 단위 유형을 설명합니다.

.service: 서비스 단위는 서버에서 서비스 또는 응용 프로그램을 관리하는 방법을 설명합니다. 여기에는 서비스를 시작 또는 중지하는 방법, 서비스가 자동으로 시작되어야 하는 상황, 관련 소프트웨어의 종속성 및 주문 정보가 포함됩니다.

.socket: 소켓 단위 파일은 네트워크 또는 IPC 소켓 또는 systemd가 소켓 기반 활성화에 사용하는 FIFO 버퍼를 설명합니다. 이들은 항상 이 유닛이 정의하는 소켓에서 활동이 보일 때 시작될 관련된 .service 파일을 가지고 있습니다.

.device: udev 또는 sysfs에 의해 systemd 관리가 필요한 것으로 지정된 장치를 설명하는 단위 파일 시스템. 모든 장치에 .device 파일이 있는 것은 아닙니다. .device 단위가 필요할 수 있는 일부 시나리오는 장치 주문, 장착 및 액세스를 위한 것입니다.

.mount: 이 단위는 systemd에서 관리할 시스템의 마운트 지점을 정의합니다. 이들은 슬래시가 대시로 변경된 마운트 경로를 따라 이름이 지정됩니다. /etc/fstab 내의 항목은 자동으로 생성된 단위를 가질 수 있습니다.

.automount: .automount 단위는 자동으로 마운트될 마운트 지점을 구성합니다. 참조하는 마운트 지점의 이름을 따서 이름을 지정해야 하며 마운트의 세부 사항을 정의하기 위해 일치하는 .mount 단위가 있어야 합니다.

.swap: 이 단위는 시스템의 스왑 공간을 설명합니다. 이러한 단위의 이름은 공간의 장치 또는 파일 경로를 반영해야 합니다.

.target: 대상 장치는 부팅하거나 상태를 변경할 때 다른 장치에 대한 동기화 지점을 제공하는 데 사용됩니다. 또한 시스템을 새로운 상태로 만드는 데 사용할 수 있습니다. 다른 유닛은 대상의 작업과 연결되도록 대상과의 관계를 지정합니다.

.path: 이 단위는 경로 기반 활성화에 사용할 수 있는 경로를 정의합니다. 기본적으로 동일한 기본 이름의 .service 단위는 경로가 지정된 상태에 도달하면 시작됩니다. 이것은 inotify를 사용하여 변경 경로를 모니터링합니다.

.timer: .timer 단위는 cron 작업과 유사하게 systemd에서 관리할 타이머를 정의합니다. 지연되거나 예정된 활성화를 위해. 타이머에 도달하면 매칭 유닛이 시작됩니다.

.snapshot: .snapshot 단위는 systemctl snapshot 명령에 의해 자동으로 생성됩니다. 변경 후 시스템의 현재 상태를 재구성할 수 있습니다. 스냅샷은 세션 간에 유지되지 않으며 임시 상태를 롤백하는 데 사용됩니다.

.slice: .slice 단위는 Linux 제어 그룹 노드와 연결되어 리소스를 제한하거나 슬라이스와 연결된 모든 프로세스에 할당할 수 있습니다. 이름은 cgroup 트리 내의 계층적 위치를 반영합니다. 유닛은 유형에 따라 기본적으로 특정 슬라이스에 배치됩니다.

.scope: 범위 단위는 버스 인터페이스에서 받은 정보로부터 systemd에 의해 자동으로 생성됩니다. 이들은 외부에서 생성된 시스템 프로세스 집합을 관리하는 데 사용됩니다.

보시다시피 systemd가 관리 방법을 알고 있는 다양한 단위가 있습니다. 많은 단위 유형이 함께 작동하여 기능을 추가합니다. 예를 들어 일부 장치는 다른 장치를 트리거하고 활성화 기능을 제공하는 데 사용됩니다.

유틸리티와 관리자가 이러한 단위를 관리해야 하는 일관성 때문에 주로 .service 단위에 초점을 맞출 것입니다.

단위 파일 분석

단위 파일의 내부 구조는 섹션으로 구성됩니다. 섹션은 한 쌍의 대괄호 "[” 및 "]”로 표시되며 그 안에 섹션 이름이 포함됩니다. 각 섹션은 다음 섹션의 시작 부분이나 파일의 끝까지 확장됩니다.

단위 파일의 일반적인 특성

섹션 이름은 잘 정의되어 있으며 대소문자를 구분합니다. 따라서 [Unit] 섹션은 철자가 [UNIT]와 같은 경우 올바르게 해석되지 않습니다. systemd 이외의 애플리케이션에서 구문 분석할 비표준 섹션을 추가해야 하는 경우 섹션 이름에 X- 접두사를 추가할 수 있습니다.

이 섹션 내에서 단위 동작 및 메타데이터는 다음과 같이 등호로 표시된 할당과 함께 키-값 형식을 사용하는 간단한 지시문을 사용하여 정의됩니다.

[Section]
Directive1=value
Directive2=value

. . .

재정의 파일(예: unit.type.d 디렉토리에 포함된 파일)이 있는 경우 지시문을 할당하여 재설정할 수 있습니다. 빈 문자열로. 예를 들어 시스템의 단위 파일 복사본에는 다음과 같은 값으로 설정된 지시문이 포함될 수 있습니다.

Directive1=default_value

다음과 같이 값 없이 Directive1을 참조하여 재정의 파일에서 default_value를 제거할 수 있습니다.

Directive1=

일반적으로 systemd는 쉽고 유연한 구성을 허용합니다. 예를 들어 여러 부울 표현식이 허용됩니다(1, yes, on 및 true는 긍정 및 0, no off 및 false 반대 답변). 단위가 없는 값을 초 단위로 가정하고 내부적으로 수행되는 여러 형식을 결합하여 시간을 지능적으로 구문 분석할 수 있습니다.

[단위] 섹션 지시어

대부분의 유닛 파일에서 발견되는 첫 번째 섹션은 [Unit] 섹션입니다. 이것은 일반적으로 장치에 대한 메타데이터를 정의하고 장치와 다른 장치의 관계를 구성하는 데 사용됩니다.

섹션 순서는 파일을 구문 분석할 때 systemd에 중요하지 않지만 이 섹션은 단위의 개요를 제공하기 때문에 종종 맨 위에 배치됩니다. [Unit] 섹션에서 찾을 수 있는 몇 가지 일반적인 지시문은 다음과 같습니다.

  • Description=: 이 지시문은 장치의 이름과 기본 기능을 설명하는 데 사용할 수 있습니다. 다양한 systemd 도구에 의해 반환되므로 짧고 구체적이며 유익한 것으로 설정하는 것이 좋습니다.
  • Documentation=: 이 지시문은 문서에 대한 URI 목록의 위치를 제공합니다. 내부적으로 사용 가능한 man 페이지이거나 웹에서 액세스 가능한 URL일 수 있습니다. systemctl status 명령은 이 정보를 노출하여 쉽게 검색할 수 있도록 합니다.
  • Requires=: 이 지시문은 이 유닛이 본질적으로 의존하는 모든 유닛을 나열합니다. 현재 유닛이 활성화된 경우 여기에 나열된 유닛도 성공적으로 활성화되어야 합니다. 그렇지 않으면 이 유닛이 실패합니다. 이러한 단위는 기본적으로 현재 단위와 병렬로 시작됩니다.
  • Wants=: 이 지시문은 Requires=와 유사하지만 덜 엄격합니다. Systemd는 이 장치가 활성화되면 여기에 나열된 모든 장치를 시작하려고 시도합니다. 이러한 장치를 찾을 수 없거나 시작에 실패하면 현재 장치가 계속 작동합니다. 이것은 대부분의 종속성 관계를 구성하는 데 권장되는 방법입니다. 다시 말하지만 이것은 다른 지시문에 의해 수정되지 않는 한 병렬 활성화를 의미합니다.
  • BindsTo=: 이 지시문은 Requires=와 유사하지만 연결된 유닛이 종료될 때 현재 유닛이 중지되도록 합니다.
  • Before=: 이 지시문에 나열된 단위는 동시에 활성화된 경우 현재 단위가 시작된 것으로 표시될 때까지 시작되지 않습니다. 이는 종속 관계를 의미하지 않으며 원하는 경우 위 지시문 중 하나와 함께 사용해야 합니다.
  • After=: 이 지시문에 나열된 단위는 현재 단위를 시작하기 전에 시작됩니다. 이는 종속 관계를 의미하지 않으며 필요한 경우 위의 지시문을 통해 설정해야 합니다.
  • Conflicts=: 현재 유닛과 동시에 실행할 수 없는 유닛을 나열하는 데 사용할 수 있습니다. 이 관계로 유닛을 시작하면 다른 유닛이 중지됩니다.
  • Condition...=: 관리자가 장치를 시작하기 전에 특정 조건을 테스트할 수 있도록 하는 Condition으로 시작하는 많은 지시어가 있습니다. 이는 적절한 시스템에서만 실행되는 일반 단위 파일을 제공하는 데 사용할 수 있습니다. 조건이 충족되지 않으면 단위를 정상적으로 건너뜁니다.
  • Assert...=: Condition으로 시작하는 지시문과 마찬가지로 이러한 지시문은 실행 중인 환경의 다양한 측면을 확인하여 장치를 활성화해야 하는지 여부를 결정합니다. 그러나 Condition 지시문과 달리 이 지시문에서는 부정적인 결과가 실패합니다.

이러한 지시문과 기타 몇 가지 지시문을 사용하여 장치에 대한 일반적인 정보와 다른 장치 및 운영 체제와의 관계를 설정할 수 있습니다.

[설치] 섹션 지시문

유닛 파일의 반대편에서 마지막 섹션은 종종 [Install] 섹션입니다. 이 섹션은 선택 사항이며 활성화 또는 비활성화된 경우 동작 또는 단위를 정의하는 데 사용됩니다. 장치를 활성화하면 부팅 시 자동으로 시작되도록 표시됩니다. 본질적으로 이것은 문제의 장치를 부팅 시 시작할 장치 라인의 어딘가에 있는 다른 장치에 래치함으로써 수행됩니다.

이 때문에 활성화할 수 있는 장치에만 이 섹션이 있습니다. 내부의 지시문은 장치가 활성화될 때 발생해야 하는 일을 지시합니다.

  • WantedBy=: WantedBy= 지시문은 장치를 활성화하는 방법을 지정하는 가장 일반적인 방법입니다. 이 지시문을 사용하면 [Unit] 섹션에서 Wants= 지시문이 수행하는 것과 유사한 방식으로 종속성 관계를 지정할 수 있습니다. 차이점은 이 지시문이 보조 장치에 포함되어 나열된 기본 장치가 상대적으로 깨끗하게 유지된다는 것입니다. 이 지시문이 포함된 유닛이 활성화되면 지정된 유닛 이름 뒤에 .wants가 추가된 /etc/systemd/system 내에 디렉토리가 생성됩니다. 이 내에서 현재 장치에 대한 심볼릭 링크가 생성되어 종속성을 생성합니다. 예를 들어 현재 장치에 WantedBy=multi-user.target이 있는 경우 multi-user.target.wants라는 디렉토리가 /etc/ 내에 생성됩니다. systemd/system(이미 사용할 수 없는 경우) 및 현재 장치에 대한 심볼릭 링크가 내부에 배치됩니다. 이 단위를 비활성화하면 링크가 제거되고 종속 관계가 제거됩니다.
  • RequiredBy=: 이 지시문은 WantedBy= 지시문과 매우 유사하지만 대신 충족되지 않으면 활성화 실패를 유발하는 필수 종속성을 지정합니다. 활성화되면 이 지시어가 있는 유닛은 .requires로 끝나는 디렉토리를 생성합니다.
  • Alias=: 이 지시문을 사용하면 다른 이름으로도 장치를 활성화할 수 있습니다. 다른 용도 중에서도 이를 통해 기능의 여러 공급자를 사용할 수 있으므로 관련 장치에서 공통 별칭 이름의 공급자를 찾을 수 있습니다.
  • Also=: 이 지시문을 사용하면 단위를 세트로 활성화 또는 비활성화할 수 있습니다. 이 유닛이 활성 상태일 때 항상 사용할 수 있는 지원 유닛은 여기에 나열할 수 있습니다. 설치 작업을 위해 그룹으로 관리됩니다.
  • DefaultInstance=: 예측할 수 없는 이름을 가진 단위 인스턴스를 생성할 수 있는 템플릿 단위(나중에 다룸)의 경우 적절한 이름이 제공되지 않은 경우 이름에 대한 대체 값으로 사용할 수 있습니다.

단위별 섹션 지시문

이전 두 섹션 사이에 있는 단위 유형별 섹션을 찾을 수 있습니다. 대부분의 유닛 유형은 특정 유형에만 적용되는 명령을 제공합니다. 이들은 해당 유형에 따라 이름이 지정된 섹션 내에서 사용할 수 있습니다. 여기에서 간략하게 다룰 것입니다.

device, target, snapshot 및 scope 단위 유형에는 단위별 지시문이 없으므로 해당 유형에 대한 관련 섹션.

[서비스] 섹션

[Service] 섹션은 서비스에만 적용 가능한 구성을 제공하는 데 사용됩니다.

[Service] 섹션 내에서 지정해야 하는 기본 항목 중 하나는 서비스의 Type=입니다. 프로세스 및 데몬화 동작에 따라 서비스를 분류합니다. 이것은 systemd에게 servie를 올바르게 관리하고 그 상태를 찾는 방법을 알려주기 때문에 중요합니다.

Type= 지시문은 다음 중 하나일 수 있습니다.

  • 단순: 서비스의 주요 프로세스가 시작 줄에 지정됩니다. Type= 및 Busname= 지시문이 설정되지 않았지만 ExecStart=가 설정된 경우 기본값입니다. 모든 통신은 적절한 유형의 두 번째 장치를 통해 장치 외부에서 처리되어야 합니다(예: 이 장치가 소켓을 사용하여 통신해야 하는 경우 .socket 장치를 통해).
  • 포킹: 이 서비스 유형은 서비스가 하위 프로세스를 분기하여 상위 프로세스를 거의 즉시 종료할 때 사용됩니다. 이는 systemd에게 부모 프로세스가 종료되더라도 프로세스가 계속 실행 중임을 알려줍니다.
  • oneshot: 이 유형은 프로세스가 수명이 짧고 systemd가 다른 장치를 계속하기 전에 프로세스가 종료될 때까지 기다려야 함을 나타냅니다. 이것은 기본 Type=이며 ExecStart=는 설정되지 않습니다. 일회성 작업에 사용됩니다.
  • dbus: 이것은 장치가 D-Bus 버스에서 이름을 가질 것임을 나타냅니다. 이 경우 systemd는 계속해서 다음 단위를 처리합니다.
  • notify: 서비스 시작이 완료되면 알림을 발행함을 나타냅니다. systemd 프로세스는 다른 장치로 진행하기 전에 이것이 발생할 때까지 기다립니다.
  • 유휴: 모든 작업이 발송될 때까지 서비스가 실행되지 않음을 나타냅니다.

특정 서비스 유형을 사용할 때 몇 가지 추가 지시문이 필요할 수 있습니다. 예를 들어:

  • RemainAfterExit=: 이 지시문은 일반적으로 oneshot 유형과 함께 사용됩니다. 프로세스가 종료된 후에도 서비스가 활성 상태로 간주되어야 함을 나타냅니다.
  • PIDFile=: 서비스 유형이 "forking\으로 표시된 경우, 이 지시문은 기본 자식의 프로세스 ID 번호를 포함해야 하는 파일의 경로를 설정하는 데 사용됩니다. 모니터링합니다.
  • BusName=: 이 지시문은 "dbus\ 서비스 유형을 사용할 때 서비스가 획득을 시도할 D-Bus 버스 이름으로 설정되어야 합니다.
  • NotifyAccess=: "notify\ 서비스 유형이 선택되었을 때 알림을 수신하는 데 사용해야 하는 소켓에 대한 액세스를 지정합니다. "none\, "main\, 또는 모두. 기본값인 "none\은 모든 상태 메시지를 무시합니다. "main\ 옵션은 기본 프로세스의 메시지를 수신하고 "all\ 옵션은 서비스 제어 그룹의 모든 구성원이 처리되도록 합니다.

지금까지 몇 가지 필수 정보에 대해 논의했지만 실제로 서비스를 관리하는 방법을 정의하지는 않았습니다. 이를 수행하기 위한 지시어는 다음과 같습니다.

  • ExecStart=: 전체 경로와 프로세스를 시작하기 위해 실행할 명령의 인수를 지정합니다. 이것은 한 번만 지정할 수 있습니다("oneshot\ 서비스 제외). 명령 경로 앞에 대시 "-\ 문자가 있으면 장치 활성화를 실패로 표시하지 않고 0이 아닌 종료 상태가 허용됩니다.< /리>
  • ExecStartPre=: 이는 기본 프로세스가 시작되기 전에 실행되어야 하는 추가 명령을 제공하는 데 사용할 수 있습니다. 이것은 여러 번 사용할 수 있습니다. 다시 말하지만 명령은 전체 경로를 지정해야 하며 명령 실패가 허용됨을 나타내기 위해 앞에 "-\를 붙일 수 있습니다.
  • ExecStartPost=: 메인 프로세스 후에 실행될 명령을 지정한다는 점을 제외하면 ExecStartPre=와 동일한 품질을 가집니다. 시작했습니다.
  • ExecReload=: 이 선택적 지시문은 사용 가능한 경우 서비스 구성을 다시 로드하는 데 필요한 명령을 나타냅니다.
  • ExecStop=: 서비스를 중지하는 데 필요한 명령을 나타냅니다. 이것이 제공되지 않으면 서비스가 중지될 때 프로세스가 즉시 종료됩니다.
  • ExecStopPost=: 중지 명령 다음에 실행할 명령을 지정하는 데 사용할 수 있습니다.
  • RestartSec=: 서비스 자동 재시작이 활성화된 경우 서비스 재시작을 시도하기 전에 대기하는 시간을 지정합니다.
  • Restart=: systemd가 자동으로 서비스를 다시 시작하려고 시도하는 상황을 나타냅니다. 이것은 "always\, "on-success\, "on-failure\, "on-abnormal\, "on-abort\ 또는 "on-watchdog\과 같은 값으로 설정할 수 있습니다. 서비스가 중지된 방식에 따라 다시 시작됩니다.
  • TimeoutSec=: 이것은 systemd가 서비스를 실패로 표시하거나 강제로 종료하기 전에 서비스를 중지하거나 중지할 때 대기하는 시간을 구성합니다. TimeoutStartSec= 및 TimeoutStopSec=를 사용하여 별도의 시간 제한을 설정할 수도 있습니다.

[소켓] 섹션

많은 서비스가 더 나은 병렬화 및 유연성을 제공하기 위해 소켓 기반 활성화를 구현하기 때문에 소켓 단위는 systemd 구성에서 매우 일반적입니다. 각 소켓 장치에는 소켓이 활동을 수신할 때 활성화될 일치하는 서비스 장치가 있어야 합니다.

서비스 자체 외부에서 소켓 제어를 중단하면 소켓을 조기에 초기화할 수 있고 관련 서비스를 병렬로 시작할 수 있습니다. 기본적으로 소켓 이름은 연결 수신 시 동일한 이름의 서비스를 시작하려고 시도합니다. 서비스가 초기화되면 소켓이 전달되어 버퍼링된 요청 처리를 시작할 수 있습니다.

실제 소켓을 지정하기 위해 다음 지시문이 일반적입니다.

  • ListenStream=: 순차적이고 안정적인 통신을 지원하는 스트림 소켓의 주소를 정의합니다. TCP를 사용하는 서비스는 이 소켓 유형을 사용해야 합니다.
  • ListenDatagram=: 빠르고 신뢰할 수 없는 통신 패킷을 지원하는 데이터그램 소켓의 주소를 정의합니다. UDP를 사용하는 서비스는 이 소켓 유형을 설정해야 합니다.
  • ListenSequentialPacket=: 이것은 메시지 경계를 보존하는 최대 길이 데이터그램을 사용하여 순차적이고 안정적인 통신을 위한 주소를 정의합니다. 이것은 Unix 소켓에서 가장 자주 발견됩니다.
  • ListenFIFO: 다른 수신 유형과 함께 소켓 대신 FIFO 버퍼를 지정할 수도 있습니다.

더 많은 유형의 청취 지시문이 있지만 위의 지시문이 가장 일반적입니다.

소켓의 다른 특성은 추가 지시문을 통해 제어할 수 있습니다.

  • Accept=: 각 연결에 대해 서비스의 추가 인스턴스를 시작할지 여부를 결정합니다. false(기본값)로 설정하면 하나의 인스턴스가 모든 연결을 처리합니다.
  • SocketUser=: Unix 소켓의 경우 소켓 소유자를 지정합니다. 설정하지 않은 경우 루트 사용자가 됩니다.
  • SocketGroup=: Unix 소켓의 경우 소켓의 그룹 소유자를 지정합니다. 이것 또는 위의 항목이 모두 설정되지 않은 경우 루트 그룹이 됩니다. SocketUser=만 설정된 경우 systemd는 일치하는 그룹을 찾으려고 시도합니다.
  • SocketMode=: Unix 소켓 또는 FIFO 버퍼의 경우 생성된 엔티티에 대한 권한을 설정합니다.
  • Service=: 서비스 이름이 .socket 이름과 일치하지 않으면 이 지시문으로 서비스를 지정할 수 있습니다.

[마운트] 섹션

마운트 장치는 systemd 내에서 마운트 포인트 관리를 허용합니다. 마운트 지점은 변환 알고리즘이 적용된 상태에서 제어하는 디렉토리의 이름을 따서 명명됩니다.

예를 들어 선행 슬래시가 제거되고 다른 모든 슬래시는 대시 "-\로 변환되며 모든 대시와 인쇄할 수 없는 문자는 C 스타일 이스케이프 코드로 대체됩니다. 이 변환 결과가 마운트 유닛 이름으로 사용됩니다. 마운트 장치는 계층 구조에서 그 위에 있는 다른 마운트에 대한 암시적 종속성을 갖습니다.

마운트 장치는 종종 부팅 프로세스 중에 /etc/fstab 파일에서 직접 변환됩니다. 자동으로 생성된 단위 정의와 단위 파일에서 정의하려는 정의의 경우 다음 지시문이 유용합니다.

  • What=: 마운트해야 하는 리소스의 절대 경로입니다.
  • Where=: 리소스를 마운트해야 하는 마운트 지점의 절대 경로입니다. 기존 파일 시스템 표기법을 사용하는 것을 제외하고는 단위 파일 이름과 동일해야 합니다.
  • Type=: 마운트의 파일 시스템 유형입니다.
  • Options=: 적용해야 하는 마운트 옵션입니다. 쉼표로 구분된 목록입니다.
  • SloppyOptions=: 인식할 수 없는 마운트 옵션이 있는 경우 마운트 실패 여부를 결정하는 부울입니다.
  • DirectoryMode=: 마운트 지점에 대해 상위 디렉토리를 생성해야 하는 경우 이 디렉토리의 권한 모드를 결정합니다.
  • TimeoutSec=: 마운트 작업이 실패로 표시될 때까지 시스템이 대기하는 시간을 구성합니다.

[자동 마운트] 섹션

이 단위를 사용하면 연결된 .mount 단위가 부팅 시 자동으로 마운트될 수 있습니다. .mount 단위와 마찬가지로 이러한 단위는 변환된 마운트 지점의 경로를 따라 이름을 지정해야 합니다.

[Automount] 섹션은 매우 간단하며 다음 두 가지 옵션만 허용됩니다.

  • Where=: 파일 시스템에서 자동 마운트 지점의 절대 경로입니다. 이것은 번역 대신 일반적인 경로 표기법을 사용한다는 점을 제외하고는 파일 이름과 일치합니다.
  • DirectoryMode=: 자동 마운트 지점 또는 상위 디렉토리를 생성해야 하는 경우 해당 경로 구성 요소의 권한 설정을 결정합니다.

[스왑] 섹션

스왑 장치는 시스템에서 스왑 공간을 구성하는 데 사용됩니다. 위에서 설명한 것과 동일한 파일 시스템 변환을 사용하여 스왑 파일 또는 스왑 장치의 이름을 따서 장치 이름을 지정해야 합니다.

마운트 옵션과 마찬가지로 스왑 단위는 /etc/fstab 항목에서 자동으로 생성되거나 전용 단위 파일을 통해 구성될 수 있습니다.

단위 파일의 [Swap] 섹션에는 구성을 위한 다음 지시문이 포함될 수 있습니다.

  • What=: 스왑 공간의 위치에 대한 절대 경로입니다. 이것이 파일이든 장치이든 상관 없습니다.
  • Priority=: 구성 중인 스왑의 우선 순위를 나타내는 정수를 사용합니다.
  • Options=: /etc/fstab 파일에서 일반적으로 설정되는 모든 옵션은 대신 이 지시문을 사용하여 설정할 수 있습니다. 쉼표로 구분된 목록이 사용됩니다.
  • TimeoutSec=: systemd가 작업을 실패로 표시하기 전에 스왑이 활성화되기를 기다리는 시간입니다.

[경로] 섹션

경로 단위는 systmed가 변경 사항을 모니터링할 수 있는 파일 시스템 경로를 정의합니다. 경로 위치에서 특정 활동이 감지될 때 활성화될 다른 유닛이 있어야 합니다. 경로 활동은 inotify 이벤트를 통해 결정됩니다.

유닛 파일의 [Path] 섹션은 다음 지시문을 포함할 수 있습니다.

  • PathExists=: 이 지시문은 해당 경로가 존재하는지 확인하는 데 사용됩니다. 그렇다면 관련 장치가 활성화됩니다.
  • PathExistsGlob=: 위와 동일하지만 경로 존재를 결정하기 위한 파일 glob 표현식을 지원합니다.
  • PathChanged=: 경로 위치에서 변경 사항을 감시합니다. 감시 파일이 닫힐 때 변경 사항이 감지되면 관련 장치가 활성화됩니다.
  • PathModified=: 이것은 위 지시문과 같은 변경 사항을 감시하지만 파일이 닫힐 때뿐만 아니라 파일 쓰기 시에도 활성화됩니다.
  • DirectoryNotEmpty=: 이 지시어는 디렉토리가 더 이상 비어 있지 않을 때 systemd가 관련 장치를 활성화하도록 허용합니다.
  • Unit=: 위에서 지정한 경로 조건이 충족될 때 활성화할 단위를 지정합니다. 이것이 생략되면 systemd는 이 장치와 동일한 기본 장치 이름을 공유하는 .service 파일을 찾습니다.
  • MakeDirectory=: 이것은 systemd가 보기 전에 해당 경로의 디렉토리 구조를 생성할지 여부를 결정합니다.
  • DirectoryMode=: 위의 기능이 활성화되면 생성해야 하는 모든 경로 구성 요소의 권한 모드가 설정됩니다.

[타이머] 섹션

타이머 단위는 특정 시간 또는 특정 지연 후에 작동하도록 작업을 예약하는 데 사용됩니다. 이 단위 유형은 cron 및 at 데몬의 일부 기능을 대체하거나 보완합니다. 타이머에 도달하면 활성화될 관련 장치가 제공되어야 합니다.

단위 파일의 [Timer] 섹션에는 다음 지시문 중 일부가 포함될 수 있습니다.

  • OnActiveSec=: 이 지시문을 사용하면 .timer 장치의 활성화와 관련하여 관련 장치를 활성화할 수 있습니다.
  • OnBootSec=: 이 지시문은 시스템이 부팅된 후 관련 장치가 활성화되어야 하는 시간을 지정하는 데 사용됩니다.
  • OnStartupSec=: 이 지시문은 위의 타이머와 유사하지만 systemd 프로세스 자체가 시작된 시기와 관련이 있습니다.
  • OnUnitActiveSec=: 연결된 장치가 마지막으로 활성화된 시간에 따라 타이머를 설정합니다.
  • OnUnitInactiveSec=: 연결된 장치가 마지막으로 비활성으로 표시된 시간과 관련하여 타이머를 설정합니다.
  • OnCalendar=: 이를 통해 이벤트에 상대적인 대신 절대값을 지정하여 관련 단위를 활성화할 수 있습니다.
  • AccuracySec=: 이 단위는 타이머가 준수해야 하는 정확도 수준을 설정하는 데 사용됩니다. 기본적으로 연결된 장치는 타이머에 도달한 후 1분 이내에 활성화됩니다. 이 지시문의 값은 systemd가 활성화를 예약하는 창의 상한을 결정합니다.
  • Unit=: 이 지시문은 타이머가 경과할 때 활성화되어야 하는 단위를 지정하는 데 사용됩니다. 설정하지 않으면 systemd는 이 단위와 일치하는 이름을 가진 .service 단위를 찾습니다.
  • Persistent=: 이것이 설정되면 systemd는 타이머가 활성화된 기간 동안 트리거되었을 경우 타이머가 활성화될 때 관련 장치를 트리거합니다. 비활성.
  • WakeSystem=: 이 지시문을 설정하면 해당 상태에서 타이머에 도달한 경우 일시 중단 상태에서 시스템을 깨울 수 있습니다.

[슬라이스] 섹션

유닛 파일의 [Slice] 섹션에는 실제로 .slice 유닛별 구성이 없습니다. 대신 위에 나열된 여러 단위에서 실제로 사용할 수 있는 일부 리소스 관리 지시문을 포함할 수 있습니다.

다른 유닛에서도 사용될 수 있는 [Slice] 섹션의 일부 공통 지시문은 systemd.resource-control 매뉴얼 페이지에서 찾을 수 있습니다. 이는 다음 단위별 섹션에서 유효합니다.

  • [슬라이스]
  • [범위]
  • [서비스]
  • [소켓]
  • [마운트]
  • [스왑]

템플릿 단위 파일에서 인스턴스 단위 생성

이 가이드의 앞부분에서 유닛의 여러 인스턴스를 생성하는 데 사용되는 템플릿 유닛 파일에 대한 아이디어를 언급했습니다. 이 섹션에서는 이 개념을 더 자세히 살펴볼 수 있습니다.

템플릿 단위 파일은 대부분의 경우 일반 단위 파일과 다르지 않습니다. 그러나 이들은 파일의 특정 부분이 런타임 시 사용할 수 있는 동적 정보를 활용할 수 있도록 하여 단위 구성에 유연성을 제공합니다.

템플릿 및 인스턴스 단위 이름

템플릿 단위 파일은 기본 단위 이름 뒤와 단위 유형 접미사 앞에 @ 기호가 포함되어 있기 때문에 식별할 수 있습니다. 템플릿 단위 파일 이름은 다음과 같습니다.

example@.service

템플릿에서 인스턴스가 생성되면 @ 기호와 단위 유형의 시작을 나타내는 마침표 사이에 인스턴스 식별자가 배치됩니다. 예를 들어 위의 템플릿 단위 파일을 사용하여 다음과 같은 인스턴스 단위를 만들 수 있습니다.

example@instance1.service

인스턴스 파일은 일반적으로 인스턴스 식별자를 포함하는 링크 이름과 함께 템플릿 파일에 대한 심볼릭 링크로 생성됩니다. 이러한 방식으로 고유 식별자가 있는 여러 링크가 단일 템플릿 파일을 다시 가리킬 수 있습니다. 인스턴스 유닛을 관리할 때 systemd는 사용할 명령줄에 지정한 정확한 인스턴스 이름을 가진 파일을 찾습니다. 찾을 수 없으면 연결된 템플릿 파일을 찾습니다.

템플릿 지정자

템플릿 단위 파일의 힘은 주로 운영 환경에 따라 단위 정의 내에서 적절한 정보를 동적으로 대체하는 기능을 통해 볼 수 있습니다. 이는 템플릿 파일의 지시문을 정상적으로 설정하지만 특정 값 또는 값의 일부를 변수 지정자로 대체하여 수행됩니다.

다음은 인스턴스 단위가 관련 정보로 해석될 때 대체될 보다 일반적인 지정자 중 일부입니다.

  • %n: 템플릿 파일에서 이것이 나타나는 모든 위치에 전체 결과 단위 이름이 삽입됩니다.
  • %N: 위와 동일하지만 파일 경로 패턴에 있는 것과 같은 모든 이스케이프가 반전됩니다.
  • %p: 유닛 이름 접두사를 참조합니다. @ 기호 앞에 오는 장치 이름 부분입니다.
  • %P: 위와 동일하지만 이스케이프 처리가 반대입니다.
  • %i: 인스턴스 단위에서 @ 뒤에 오는 식별자인 인스턴스 이름을 참조합니다. 동적임을 보장하기 때문에 가장 일반적으로 사용되는 지정자 중 하나입니다. 이 식별자를 사용하면 구성에 중요한 식별자를 사용할 수 있습니다. 예를 들어 서비스가 실행될 포트를 인스턴스 식별자로 사용할 수 있으며 템플릿은 이 지정자를 사용하여 포트 사양을 설정할 수 있습니다.
  • %I: 이 지정자는 위와 동일하지만 모든 이스케이프가 반전됩니다.
  • %f: 이스케이프 처리되지 않은 인스턴스 이름 또는 /가 앞에 추가된 접두사 이름으로 대체됩니다.
  • %c: /sys/fs/cgroup/ssytemd/의 표준 상위 계층 구조가 제거된 장치의 컨트롤 그룹을 나타냅니다.
  • %u: 장치를 실행하도록 구성된 사용자의 이름입니다.
  • %U: 위와 동일하지만 이름 대신 숫자 UID입니다.
  • %H: 장치를 실행 중인 시스템의 호스트 이름입니다.
  • %%: 리터럴 백분율 기호를 삽입하는 데 사용됩니다.

템플릿 파일에서 위의 식별자를 사용하면 systemd는 템플릿을 해석하여 인스턴스 단위를 만들 때 올바른 값을 채웁니다.

결론

systemd로 작업할 때 단위 및 단위 파일을 이해하면 관리가 더 쉬워집니다. 다른 많은 init 시스템과 달리 서비스 또는 시스템을 부팅하는 데 사용되는 init 파일을 해석하기 위해 스크립팅 언어를 알 필요가 없습니다. 단위 파일은 활성화 시 단위의 목적과 효과를 한 눈에 볼 수 있는 매우 간단한 선언적 구문을 사용합니다.

활성화 논리와 같은 기능을 별도의 단위로 나누면 내부 systemd 프로세스가 병렬 초기화를 최적화할 수 있을 뿐만 아니라 구성을 다소 단순하게 유지하고 일부 단위를 분해 및 재구축하지 않고도 수정하고 다시 시작할 수 있습니다. 관련 연결. 이러한 기능을 활용하면 관리 중에 더 많은 유연성과 권한을 얻을 수 있습니다.