[오픈소스컨설팅]systemd on rhel7

Systemd with RHEL 7

주식회사 오픈소스컨설팅

박 현 익

Systemd 소개 Ⅰ

Ⅱ

Ⅲ

Systemd 특장점

Systemd 의 부팅

Ⅳ Systemd 유닛 파일의 구조

Ⅴ Systemd 주요 명령어

Systemd 소개 I

4 - Internal Use Only -

Systemd 란?

Systemd 는 systemd가 곧 시스템이며, 리눅스를 위한 서비스 매니저입니다

Systemd 는 Sys V init 스크립트와 호환되도록 만들어 졌으며, 다수의 기능을 제공합니다

이전 버전의 리눅스에서 불리우던 Upstart를 그대로 대체합니다

시스템 Snapshot 또는 의존성 기반의 서비스 컨트롤 로직을 지원합니다

Systemd는 유닛이라는 단위로 시스템을 관리합니다

On-Demand 서비스 시작 방법으로 좀 더 나은 트랜젝션과 의존성 컨트롤이 가능합니다

Systemd 의 병렬처리로 인하여 시스템 부팅시간을 비약적으로 줄였습니다


Systemd 의 유닛

Systemd는 시스템을 유닛 단위로 관리하며 각 유닛은 이름만으로도 각 각의 특징을 알 수 있습니다

유닛 타입 파일 확장자 설명

Service unit .service 시스템 서비스

Target unit .target Systemd 유닛의 그룹

Automount unit .automount automount 포인트

Device unit .device 커널에 의해 생성된 디바이스

Mount unit .mount 마운트 포인트

Path unit .path 파일시스템에 존재하는 디렉토리나 파일

Scope unit .scope 외부에서 만들어진 프로세스

Slice unit .slice 시스템 프로세스를 매니지하는 유닛들이 계층적 구성된 그룹

Snapshot unit .snapshot systemd 매니저의 상태를 저장하는 스냅샷

Socket unit .socket 내부 프로세스통신 소켓

Swap unit .swap 스왑 디바이스나 스왑파일이

Timer unit .timer 시스템 타이머

Systemd 유닛의 위치 설명

/usr/lib/systemd/system RPM 설치시 배포되는 유닛의 위치

/run/systemd/system Runtime 시에 생성된 systemd 유닛. 이 디렉토리는 설치시에 배포된 디렉토리와 유닛보다 우선순위가 높음

/etc/systemd/system 시스템 관리자가 생성되고 관리되는 디렉토리. 이 디렉토리는 Runtime 유닛 디렉토리 보다 우선순위가 높음


Systemd 의 변경점 (이번 버전 대비)

Systemd 시스템과 서비스 매니저는 SysV init과 upstart에 호환 되도록 디자인 되어있습니다

Systemd는 몇가지의 target을 제공하며, 이 target 들은 호환성을 위해 그전에 불리우던 런레벨과

매핑됩니다. 하지만 모든 target이 runlevel과 매핑되지는 않습니다. 그러므로 되도록 runlevel 커맨드를

사용하지 않으시는 것이 좋습니다

systemctl 커맨드는 start, stop, status 와 같은 표준 커맨드는 SysV init 스크립트에 구현 가능지만 기타

다른 커스텀 커맨드는 지원하지 않습니다 (예시 : systemctl iptables panic)

systemctl 유틸리티는 systemd를 통해서 시작하지 않은 서비스와 커뮤니케이션 하지 않습니다. Systemd가

서비스를 시작시킬때, systemd는 해당 서비스를 tracking 하기 위해 메인 PID를 저장합니다. 결과적으로

systemctl 유틸리티는 서비스를 관리하고 서비스쪽으로 쿼리를 보내기 위해서 PID를 사용하게 됩니다.

따라서 유저가 별도의 데몬을 직접 시작하였다면, systemctl 커맨드를 사용할 수 없습니다

Systemd는 실행중인 서비스만 정지 시킬수 있습니다. 이전버전의 리눅스에서는 shutdown 시퀀스가

시작되었을때, 서비스 상태에 상관 없이 /etc/rc0.d/ 디렉토리에 있는 스크립트를 사용하여 사용 하여 정지가

가능했지만 Systemd는 오직 실행중인 데몬만 정지가 가능합니다


Systemd 의 변경점 (이번 버전 대비)

시스템 서비스는 standard input stream을 읽을 수 없습니다. 시스템이 서비스를 시작할때, 대화형 진행을

막고자 서비스의 스탠다드 input을 /dev/null로 연결합니다

시스템 서비스는 유저나 세션으로 부터 어떤 컨텍스트(Home 또는 환경변수) 도 상속받지 않습니다. 각 각의

서비스는 깨끗한 환경에서 실행됩니다.

Sys V Init을 로딩할때에 Systemd는 LSB (Linux Standard Base)로 인코딩 된 dependency 정보를 읽어

들입니다. 그리고 런타임 상태에서 해석합니다

서비스 유닛의 모든 작동은 시스템 프리징시에 잘못된 작동을 막기 위해서 기본적으로 5분의 timeout 을

가지고 있습니다. 이 값은 initscript에서 서비스를 위해서 하드코딩 된 것이며, 변경할 수 없습니다. 그러나

개인 설정파일은 서비스 별로 더 긴 timeout시간을 가질수 있도록 할 수 있습니다

Systemd 특장점 I I


Systemd 특장점

기능 설명

서비스 활성화

systemd 기반으로 옮겨지면서 서비스들은 런레벨에 맞춰서 항상 실행되거나 항상 정지되거나 하는 방법으로 활성화 되

지 않습니다. 서비스들은 이제 path / socket / bus / timer 등에 기반하여 활성화 되거나 또는 하드웨어 상태에 따라 활성

화 됩니다. 마찬가지로 systemd가 socket을 세팅할 수 있기 때문에 만약 어떤 프로세스와 커뮤니케이션을 하는 다른 프

로세스가 갑자기 사라질 경우, 그 자리에서 다시 시작할 수 있도록 소켓을 통해 메시지를 받을 수 있습니다. 그러므로 클

라이언트 입장에서는 다른 방해 없이 서비스를 이용하는 것처럼 느낄 수 있습니다

리소스 관리

각 각의 systemd unit는 항상 그들의 Cgroup에서 컨트롤 해준 일정량의 리소스를 사용할수 있도록 되어 있습니다. 예를

들면 관리자는 특정 서비스에게 일정량의 CPU 사용률을 사용하도록 설정할 수 있습니다. 다른 말로 하면 특정서비스가

추가로 더 많은 CPU와 리소스를 사용할 수 없도록 할 수도 있습니다. systemd 이전에는 nice 값으로 프로세스의 cpu 점

유율을 컨트롤 했었지만 systemd는 cgroup을 사용하여 더 정확한 CPU 와 RAM 및 다른 리소스까지도 사용을 제한 할

수 있습니다

Slice

slice라 불리는 기능은 시스템에 있는 다양한 리소스 타입을 나누고 user / service / virtual machine / unit 등에게 할당

할 수 있습니다. 또한 이 리소스들을 계산할수도 있습니다. 이 기능을 통하여 고객들의 리소스 사용량에 따라 요금을 부

여할 수도 있습니다


Systemd 특장점 (2)

기능 설명

로깅

RAM Disk가 마운트 되는 시점부터 시스템이 다운되는 시점까지의 모든 로그가 systemd의 저널에 저장됩니다. systemd

journal이 존재하기전인 부트 초기화 단계의 메시지는 저장되지 않습니다. 이 경우는 직접 콘솔 화면을 스크롤 해서

debug를 해야합니다. 이제는 모든 시스템 메시지가 하나의 스트림으로 들어오고 /run 디렉토리에 저장됩니다. 또한 메

시지는 rsyslog로 변경할 수 있습니다. (전통적인 로그 디렉토리인 /var/log 디렉토리로 보내거나 원격 로그서버로 보내

질 수 있습니다.) 또는 journalctl을 통해서 디스플레이 할 수도 있습니다

의존성

systemd는 부트순서에 따라서가 구동 되는 것이 아닌 각 각의 서비스에 명백한 의존성을 정의하여 실행되며, 이 것은 각

서비스가 의존성만 충족된다면 어떤 시점에서도 실행될 수 있음을 말합니다. 많은 서비스들은 같은 시간에 시작될 수 있

으며, 이것은 부트 프로세스를 더욱 빠르게 만듭니다. 마찬가지로 복잡한 의존성을 설정할 수도 있습니다. 그래서 서비

스 시작전에 정밀한 의존성(스토리지나 파일시스템 등)을 요구하도록 해야합니다

Cgroups

서비스들은 Cgroups에 의해서 식별됩니다. 이 말은 모든 서비스의 컴포넌트들이 관리된다는 말입니다. 예를 들면

System V init scripts의 프로세스는 스스로 자식 프로세스를 시작하거나 다른 프로세스들을 시작시킬 수 있습니다. 또

한 init scripts 프로세스의 부모 프로세스가 죽을때 자식 프로세스도 같이 죽는것이 올바른 로직이라고 볼 수 있습니다.

(init scripts의 그렇지 않는 경우를 설명하는 부분입니다) Cgroups 를 사용한다면 서비스의 모든 컴포넌트들이 시작되었

는지 정지상태인지에 대한 태그를 가지고 있습니다 (서비스에 관련된 모든 컴포넌트가 관리가 된다는 얘기 입니다)

Systemd 의 부팅 I I I


Systemd Boot 의존성

init 과 같은 엄격하게 정해진 프로세스를 없지만 부트 프로세스를 위한 구조가 존재합니다


Systemd Boot Process

local-fs.target : /etc/fstab에 있는 파일시스템을

마운트합니다.

swap.target : Swap 영역을 활성화 합니다

①



sysinit.target : 시스템 initializing 서비스를 시작합니다

파일시스템 마운트

Logging 활성화

kernel 옵션 세팅

하드웨어 감지를 위한 udevd 시작

파일시스템 복호화

iSCSI / multipath / LVM monitoring / Raid

②



Basic.target : Basic 서비스를 시작합니다

firewalld

microcode

SELinux 를 위한 서비스 시작

Kernel 메시지를 위한 서비스 시작

/usr/lib/systemd/system/basic.target.wants 에서

모듈을 로딩

③



multi-user.target : /etc/systemd/system/multi-

user.target.wants 에 있는 서비스를 시작합니다

abrt-ccpp.service

avahi-daemon.service

hypervvssd.service

mdmonitor.service

rsyslog.service

abrtd.service

chronyd.service

irqbalance.service

...

④



graphical.target : /lib/systemd/system/graphical.target

을 시작합니다

gnome-display-manager 시작

⑤



시스템 관리자로 부터 변경될 수 있는 기본 시작 target

파일입니다. 어떤 파일에 링크가 되어 있는지에 따라

해당 target 으로 부팅됩니다

Systemd 유닛 파일의 구조 Ⅳ


Systemd 유닛 파일의 구조

Unit 파일은 전통적으로 3가지 섹션으로 구성 되어있습니다.

지시자 설명

[Unit] Unit의 type에 의존적이지 않는 일반적인 옵션을 포함합니다. 이 옵션은 Unit을 설명하고 Unit의 동작을 정의합니다. 그

리고 다른 유닛과의 Dependency를 설정합니다

[Unit type] 특정 유닛이 type-specific 지시자를 가지고 있다면 해당 옵션에 대한 항목을 참조하여 유닛파일을 작성하거나 파악해야

합니다

[Install] 인스톨 관련 정보를 담고 있습니다. systemctl enable과 systemctl disabled 에 의한 동작이 기술되어 있습니다


[Unit] 섹션

옵션 설명

Description 유닛에 대한 전반적인 설명을 기술합니다. 이 영역은 systemctl status 커맨드를 사용할때 표시됩니다

Documentation 유닛에 대한 문서를 참조할만한 URI 리스트를 기재하는 곳입니다

After After에 정의된 유닛이 활성화 된 이후에 유닛이 활성화 되어야 합니다. Requires와는 다르게 After는 After에 명시된

유닛을 활성화 시키지는 않습니다. Before는 After와 반대되는 기능의 옵션입니다

Requires Requires에 정의된 유닛 리스트에 의존성이 있음을 말합니다. Requires 리스트에 있는 유닛은 이 유닛과 같이 활성화

됩니다. 만약 Requires에 있는 유닛이 fail이 된다면, 이 유닛도 활성화 되지 못합니다

Wants Rqueires 보다는 약한 의존성을 나타냅니다. Wants에 있는 유닛이 fail이 되더라도 이 유닛을 활성화 될 수 있습니다

Conflicts Requires와 반대로 여기에 명시된 유닛이 활성화 되어 있다면 이 유닛을 활성화 될 수 없습니다


[Unit type] 섹션

옵션 설명

Type

유닛의 시작 타입을 지정합니다. 아래와 같은 타입들이 존재합니다

• simple - 기본적인 형태이며, ExecStart에 있는 것이 메인 프로세스입니다

• forking - 이미 시작된 ExecStart 프로세스에서 child 프로세스를 생성하고 그 child 프로세스가 서비스의 main 프로세스가 됩니다. 프로세스가 시작되면 부모 프로세스는 사라집니다

• oneshot - simple과 유사합니다. 다음 유닛이 시작되기 전에 사라집니다

• dbus - simple과 유사합니다. 메인 프로세스가 D-Bus 라는 이름을 얻게 될 경우만 다음 유닛이 시작됩니다

• notify - simple과 유사합니다. sd_notify() 펑션을 이용해서 메시지가 전달된 이후에만 다음 유닛이 시작됩니다

• idle - simple과 유사합니다. 모든 job이 끝날때까지 실질적인 실행이 지연됩니다

ExecStart 유닛이 시작되고 난 후 실행될 스크립트 커맨드를 정의 하는 곳입니다

ExecStop 유닛이 정지되고 난 후 실행될 스크립트 커맨드를 정의 하는 곳입니다

Restart 이 옵션이 정의되면 해당 프로세스가 모두 종료된 후 서비스가 재시작됩니다

RemainAfterExit True 로 설정하게 되면 프로세스가 종료된 후에도 서비스가 활성화 되어 있는 것으로 간주합니다. 기본값은 false 입니

다


[Install] 섹션

옵션 설명

Alias 이 유닛의 별명을 설정할 수 있으며, 각 별명은 space로 구분됩니다

RequiredBy 이 유닛에게 의존성이 있는 유닛 리스트 입니다. 이 유닛이 활성화 되면 RequiredBy 리스트에 있는 유닛들은

Require 를 얻습니다

WantedBy 이 유닛에게 Wants를 갖는 유닛 리스트 입니다. 이 유닛이 활성화 되면 WantedBy 리스트에 있는 유닛들은 Want

를 얻습니다

Also Also 리스트에 있는 유닛은 이 유닛이 삭제되거나 설치될때 같이 삭제되거나 설치됩니다

DefaultInstance 유닛이 활성화 될 때 인스턴스화 될 유닛을 제합니다

Systemd 주요 명령어 Ⅴ


[Unit] 섹션

커맨드 설명

systemctl status <서비스명> 서비스의 상태 체크

systemctl stop <서비스명> 서비스의 정지

systemctl start <서비스명> 서비스의 시작

systemct enable <서비스명> 부트시 서비스 시작 활성화

systemctl disable <서비스명> 부트시 서비스 시작 비활성화

systemctl list-dependencies <서비스명> 서비스의 디펜던시를 출력

systemctl list-units --type <타입> 특정 타입을 출력

systemctl list-unit-files 시스템에 있는 모든 유닛의 리스트와 상태를 출력

systemctl list-unit-files 시스템에 있는 모든 유닛의 리스트와 상태를 출력

systemd-cgtop 각 각의 서비스가 사용하는 리소스를 보는 커맨드

systemd-cgls 각 각의 서비스에 할당되어 있는 프로세스를 출력

journalctl -k 현재 부트에서 kernel 메시지를 출력

journalctl -f 지속적으로 로그를 출력

journalctl -u 특정 unit에 대한 메시지를 출력


요약

OPEN

SHARE

CONTRIBUTE

ADOPT

REUSE

[오픈소스컨설팅]systemd on rhel7

Software