systemctl은 systemd 관리자에 요청을 보냅니다. 이 수업은 시스템 서비스 단위에 초점을 맞춥니다. 상태를 변경하기 전에 정확한 단위 이름, 관리자 범위, 의존성 및 운영 영향을 확인하십시오.
Init · 레슨 6
Systemd 목표
systemd 서비스 단위를 검사, 재정의, 검증, 시작, 활성화 및 문제 해결하는 방법을 알아봅니다.
서비스 단위 읽기
최소한의 예시 단위는 다음과 같습니다.
[Unit]
Description=Example worker
Wants=network-online.target
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]에는 설명과 의존 관계가 있습니다.[Service]는 프로세스 수명 주기와 서비스별 동작을 정의합니다.[Install]은 활성화 명령이 만들 별칭이나 의존성 링크를 알려 주며 자동으로 활성 런타임 의존성이 되지는 않습니다.
ExecStart=는 기본적으로 셸을 통해 전달되지 않습니다. 명시적으로 셸을 호출하지 않는 한 셸 파이프라인, 리디렉션, 변수 및 인용은 대화형 명령줄처럼 동작하지 않습니다.
WantedBy= 같은 [Install] 지시문의 주된 목적은 무엇입니까?
유효 설정 검사하기
로드된 단위를 나열합니다.
$ systemctl list-units --type=service
설치된 단위 파일과 활성화 상태를 나열합니다.
$ systemctl list-unit-files --type=service
두 명령은 서로 다른 뷰입니다. 단위 파일은 활성화되었지만 비활성 상태, 활성 상태이지만 비활성화된 상태, 정적, 생성됨, 임시, 마스크됨일 수 있으며 목록 하나에는 나타나지 않을 수도 있습니다. 병합된 공급업체 및 드롭인 내용을 검사합니다.
$ systemctl cat UNIT.service
$ systemctl show UNIT.service
list-unit-files가 주로 보여 주고 list-units는 주로 보여 주지 않는 것은 무엇입니까?
로컬 재정의 만들기
패키지 단위를 편집하지 말고 드롭인을 사용합니다.
$ sudo systemctl edit UNIT.service
현재 구현에서는 저장 후 이 편집 작업 흐름의 일부로 systemctl이 일반적으로 관리자에 다시 불러오기를 요청합니다. 다른 방식으로 파일을 변경했다면 다음 명령을 실행합니다.
$ sudo systemctl daemon-reload
daemon-reload는 단위 정의를 다시 읽고 의존성을 재구성합니다. 애플리케이션 설정을 다시 불러오거나 실행 중인 서비스를 재시작하지는 않습니다. 적절한 경우 systemd-analyze verify로 단위 구문과 의존성을 검증한 다음 병합된 유효 단위를 검토하십시오.
systemctl daemon-reload는 무엇을 합니까?
런타임 서비스 상태
서비스 설정을 검증하고 복구 접근을 보존한 뒤 다음 명령을 사용합니다.
$ sudo systemctl start peanut.service
$ sudo systemctl stop peanut.service
$ sudo systemctl restart peanut.service
$ sudo systemctl reload peanut.service
reload는 단위가 다시 불러오기 작업을 정의하거나 지원할 때만 성공합니다. restart는 프로세스를 중단하며 서비스를 복원하지 못할 수 있습니다. 원격 접근, 네트워킹, 저장 장치 또는 인증에는 별도 콘솔 경로를 유지하고 작업 전에 설정을 검증하십시오.
상태와 로그를 확인합니다.
$ systemctl status peanut.service
$ systemctl is-active peanut.service
$ journalctl -u peanut.service -b
“활성”은 관리자 상태이며 모든 애플리케이션 엔드포인트가 정상이라는 증거는 아닙니다.
향후 활성화 상태를 바꾸지 않고 지금 peanut.service를 시작하는 명령은 무엇입니까?
활성화, 비활성화 및 마스킹
향후 의존성 링크를 관리합니다.
$ sudo systemctl enable peanut.service
$ sudo systemctl disable peanut.service
enable은 --now를 추가하지 않으면 단위를 시작하지 않습니다. disable은 --now를 추가하지 않으면 실행 중인 단위를 중지하지 않습니다. 정적 단위는 설치 메타데이터가 없어도 다른 단위의 의존성으로 활성화될 수 있습니다.
마스킹은 단위를 /dev/null에 연결하고 마스크를 해제할 때까지 의존성 활성화를 포함한 일반 활성화를 차단합니다. disable보다 강하며 의존 항목을 손상시킬 수 있으므로 사용 전에 역방향 의존성을 검사하십시오.
--now 없이 systemctl disable UNIT을 실행하면 이미 실행 중인 서비스는 어떻게 됩니까?
서비스 결과 검증하기
변경 후 프로세스 상태, 최근 로그, 수신 엔드포인트, 의존 단위, 애플리케이션 상태 및 부팅 활성화가 바뀌었다면 제어된 재부팅 후 동작을 검증하십시오. 적절한 경우 systemctl is-failed, systemctl list-dependencies 및 애플리케이션 고유 검사를 사용합니다.
레슨 완료
Systemd 목표 완료
이제 설정, 런타임 및 활성화를 혼동하지 않고 systemd 서비스를 관리할 수 있습니다.
[Unit],[Service]및[Install]의 서로 다른 역할을 읽습니다.로드된 단위 상태와 설치된 단위 파일 상태를 비교합니다.
드롭인을 사용하고 외부 파일 변경 후 관리자를 다시 불러옵니다.
영향을 검토한 뒤에만 시작, 중지, 다시 불러오기 또는 재시작합니다.
enable, disable 및 mask를 서로 다른 영구 제어로 취급합니다.