[Linux] systemd 초기화 데몬

 

 

2015년 이후 대부분의 리눅스 배포판은 systemd를 채택하여 기존 Init 데몬이 수행하던 초기화 시스템을 대체하였다. 

 

 

systemd 프로세스

커널은 사용자 환경을 준비하기 위해서 systemd 프로세스를 시작시키며 모든 제어권을 sysgtemd에게 넘긴다. systemd 프로세스는 커널이 가장 처음 실행하는 사용자 프로세스로 PID 1번을 가진다. '커널 프로세스'를 제외한 모든 사용자 프로세스의 부모 또는 조상 프로세스가 된다. 이 프로그램을 '초기화 데몬' 이라고 하며, 나머지 부팅 과정을 담당하고 최종적으로는 사용자 환경을 준비하는 기능을 한다.

 

systemd 의 주요 기능

1) 파일 시스템 마운트 : /etc/fstab 파일을 읽어 파일 시스템을 마운트

2) 시스템 서비스 활성화 : 부팅 과정에서 실행될 서비스를 활성화하고 시스템 서비스를 병렬로 실행

3) 의존성 해결 : 서비스가 실행되기 전에 필요로 하는 다른 서비스를 자동으로 실행시킴으로써 서비스 간의 의존성을 해결

4) 로그인 서비스 시작 : 시스템이 부팅될 때 사용자 로그인 서비스를 자동으로 시작

5) 시스템 상태 모니터링 : 부팅된 시스템의 상태를 모니터링하고 시스템 상태의 스냅샷을 저장

6) 데몬 관리 : 실행 중인 데몬 프로세스를 관리

7) 로그 관리 : systemd의 일부인 journald 를 통해 시스템 로그와 서비스 로그를 수집하고 저장

 

 

systemd unit

systemd 에서는 유닛이라는 개념을 사용합니다. 유닛이란 '유닛 설정 파일(유닛 파일)'로 표현되며, systemd가 관리하는 대상을 의미합니다. 유닛에는 여러가지 유형이 존재합니다.

유닛 유형	유닛 설정 파일 확장자	설명
service	.service	일반적인 데몬(서비스)
target	.target	여러 유닛을 묶은 그룹 ex) multi-user.target / graphical.target
device	.device	커널이 인식한 디바이스 파일
mount	.mount	파일 시스템 마운트 지점
path	.path	파일/디렉터리 변경을 감시하여 특정 서비스를 실행
socket	.socket	프로세스 간 통신에 사용되는 소켓
snapshot	.snapshot	시스템 상태
timer	.timer	특정 시간/주기마다 유닛 실행(cron 대체 가능)
slice	.slice	리소스 제어 그룹(cgroup) 단위 설정
scope	.scope	외부 프로세스(systemd 외)가 systemd에 의해 관리되도록 설정

 

📌 하기 이미지와 같은 .target.wants 확장자는 무엇을 의미하나요?

.target.wants는 systemd의 의존성 설정 디렉토리 입니다. 이 확장자는 유닛 파일이 아닌 디렉토리 이름에 붙으며, 특정 .target
유닛이 활성화 될 때 함께 시작되어야 하는 유닛들의 심볼릭 링크를 보관하는 디렉토리 입니다.

예시를 들자면 아래와 같은 파일 구조의 경우 multi-user.target이 실행될 때 sshd, nginx도 자동으로 실행됩니다.

/etc/systemd/system/
├── multi-user.target.wants/
│   ├── sshd.service -> /lib/systemd/system/sshd.service
│   └── nginx.service -> /lib/systemd/system/nginx.service​

보통 이러한 디렉토리는 systemctl enable [서비스명] 을 실행할 때 자동으로 자동으로 실행됩니다. 아래와 같이 명령어를 실행하면 /etc/systemd/system/multi-user.target.wants/nginx.service 심볼릭 링크가 생성됩니다.

systemctl enable nginx.service

 

유닛 파일이 존재하는 디렉토리는 주로 아래 3가지 입니다. systemd는 유닛 파일을 첫 번째 디렉토리에서부터 순차적으로 탐색합니다. 같은 이름의 유닛이 여러 디렉토리에 존재할 경우 더 높은 우선 순위의 유닛 파일이 적용됩니다.

디렉토리 경로	설명
/etc/systemd/system/	사용자가 직접 정의하거나 수정한(override) 유닛 파일
/run/systemd/system/	시스템이 실행 중일 때 생성되는 유닛 파일로, 시스템의 런타임 중에 발생하는 비지속적인 수정사항을 담당 여기에 저장된 파일들은 시스템이 재부팅되면 사라지므로, 임시적인 변경을 위해 사용 예를 들어, 시스템의 현재 실행 세션에만 적용될 서비스 변경사항을 반영할 때 이용
/usr/lib/systemd/system/ 또는 /lib/systemd/system/	소프트웨어 패키지를 설치할 때 함께 설치된 유닛 파일

 

📌 유닛 파일이 존재하는 디렉토리를 살펴보면 [unit-name].d 형태의 디렉토리를 확인할 수 있습니다. 이는 무엇일까요?

해당 디렉토리는 Drop-in(부분 수정) 설정 디렉토리로 기존 유닛 파일을 직접 수정하지 않고도 유닛의 동작을 사용자 정의 방식으로 변경할 수 있는 안전하고 유연한 방법 입니다.

원본 유닛 파일

user@.service.d 디렉토리 하위에 timer.conf를 살펴보면 아래와 같이 TimeoutStopSec이 5초로 적혀있음을 볼 수 있습니다.
이 경우 Drop-in 설정 값이 기존 유닛 파일 값을 덮어 씁니다.

Drop-in 유닛 파일

하지만 모든 설정이 위 처럼 Drop-in을 할 수 있는 것은 아닙니다. 설정 값마다 Drop-in 하는 방식이 다릅니다.
예를 들어 아래와 같이 기존 유닛 파일이 daily로 설정되어 있고 weekly로 Drop-in 하는 경우 Timer의 값이 weekly로 변경되는 것이 아니라 'daily', 'weekly' 모두 적용됩니다. 그 이유는 OnCalendar는 여러 개의 값을 포함할 수 있기 때문입니다.

# 기존 유닛 파일
[Timer]
OnCalendar=daily

# Drop-in 유닛 파일
[Timer]
OnCalendar=weekly

만약 weekly로만 수정하고 싶다면 아래처럼 Drop-in을 해야 합니다.

[Timer]
OnCalendar=         # 값을 공백으로 초기화
OnCalendar=weekly   # weekly로 수정

 

컴파일 중에 정해지는 systemd의 기본 설정은 /etc/systemd/system.conf 파일에서 찾을 수 있습니다. 이 설정 파일에 존재하는 설정값을 수정하면 전역적으로 적용되는 파라미터를 설정할 수 있습니다.

 

 

시스템 서비스 관리

과거에 사용하던 'init 데몬' 이나 'Upstart 데몬'은 /etc/rc.d/init.d 디렉토리에 존재하는 초기화 스크립트(Bash)를 사용했습니다. 하지만 현재는 초기화 스크립트가 서비스 유닛으로 대체되었습니다. 서비스 유닛은 확장자가 .service인 파일로 제공됩니다.

관리자는 systemctl 명령을 사용하여 시스템 서비스의 상태 확인, start, stop, restart, enable, disable 작업을 수행할 수 있습니다. service 명령과 chkconfig 명령이 아직도 사용 가능하지만, 호환성을 위해 제공될 뿐 현재 리눅스 배포판에서는 systemctl을 사용하고 있습니다.

systemctl 명령	service / chkconfig 설명	설명
systemctl start name.service	service name start	서비스 시작
systemctl stop name.service	service name stop	서비스 중지
systemctl restart name.service	service name restart	서비스 재시작
systemctl try-restart name.service	service name condrestart	실행 중인 경우에만 서비스를 재시작
systemctl reload name.service	service name reload	설정을 다시 로드
systemctl status name.service	service name status	특정 서비스 상태를 확인
systemctl list-units --type=service --all	service --status-all	모든 서비스 상태를 확인
systemctl enable name.service	chkconfig name on	부팅 시 서비스가 자동 시작 되도록 활성화
systemctl disable name.service	chkconfig name off	서비스 비활성화
systemctl list-depencencies --after name.service	-	지정된 유닛 후에 시작하도록 된 서비스를 나열
systemctl list-depencencies --before name.service	-	지정된 유닛 전에 시작하도록 된 서비스를 나열

 

 

유닛 파일 구조

유닛 파일은 일반적으로 세 가지 섹션으로 구분됩니다. 

 

[Unit]

유닛 유형에 관계없이 공통적으로 사용되는 일반 옵션들이 포함됩니다. 해당 섹션에서는 유닛에 대한 설명(Description), 유닛의 동작 방식, 다른 유닛과의 의존 관계를 설정합니다.  다음 링크에서 자세한 옵션 확인이 가능합니다.

 

[Unit Type]

유닛 유형에 따라 옵션들이 달라집니다. 예를 들어 서비스 유닛 설정 파일의 경우 해당 섹션을 '[Service]'로 지정합니다.

다음 링크에서 자세한 옵션 확인이 가능합니다.

 

[Install]

'systemctl enable' 및 'disable' 명령어가 실행될 때 함께 자동으로 실행되어야 하는 유닛 관련 정보를 포함합니다.

다음 링크에서 자세한 옵션 확인이 가능합니다.

 

예시를 통해 살펴보도록 하겠습니다. 현재 실행 중인 nginx 서비스 유닛 파일을 살펴보면 아래와 같이 설정이 되어 있는 것을 볼 수 있습니다.

 

[Unit]

After : nginx는 network와 nss-lookup이 활성화된 이후에 실행됩니다.

 

[Service]

Type : ExecStart로 시작된 프로세스가 자식 프로세스(nginx)를 생성합니다.

PIDFile : nginx의 마스터 프로세스 PID(프로세스 ID)가 저장되는 위치입니다.

ExecStartPre : nginx를 시작하기 전에 실행되는 명령어 입니다.

ExecStart : nginx를 실행할 때 실행되는 명령어 입니다.

ExecReload : systemctl reload nginx 명령 시 실행됩니다.

ExecStop : nginx를 종료할 때 실행되는 명령어입니다. 

TimeoutStopSec : 종료 명령을 보내고 대기하는 시간 입니다.

KillMode : 기본적으로 마스터 프로세스에는 SIGTERM을, 워커 프로세스에는 SIGKILL을 보내는 방식입니다.

 

[Install]

WantedBy : systemctl enable nginx 명령을 실행하면, nginx.service 유닛이 multi-user.target에 종속되도록 심볼릭 링크가 생성됩니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

참고 자료

https://dev.to/redrum_yot/understanding-drop-in-overrides-in-systemd-when-parameters-accumulate-vs-override-3noi

Understanding Drop-in Overrides in systemd: When Parameters Accumulate vs Override

https://cumulus.tistory.com/158

Linux systemd 완전 정복하기

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_systemd_unit_files_to_customize_and_optimize_your_system/assembly_working-with-systemd-unit-files_working-with-systemd

Chapter 1. Working with systemd unit files | Using systemd unit files to customize and optimize your system | Red Hat Enterpri