systemd, Linux PID 1번의 이름을 가진자

1. systemd ?

리눅스 시스템의 새로운 표준

systemd는 리눅스에서 프로세스와 서비스를 관리하는 현대적인 init 시스템입니다. 기존의 SysVinit과 Upstart를 대체하며, 빠른 부팅과 강력한 서비스 관리 기능을 제공하는데, 현재 Ubuntu, Debian, Fedora, CentOS 등 거의 모든 주요 배포판에서 기본 init 시스템으로 사용되고 있습니다.

 

* init(initialization) 시스템은 리눅스와 유닉스 계열 운영체제에서 부팅 후 가장 먼저 실행되는 프로세스로, 시스템을 초기화하고 서비스(데몬)를 실행하는 역할을 담당합니다. 시스템이 켜지면 init 시스템이 커널에 의해 실행되며, 이후 다양한 시스템 서비스(예: 네트워크, 로깅, 데이터베이스 등)를 시작하고 프로세스를 관리하는 핵심 역할을 수행하게 됩니다.

 

 

* 특수한 환경에서는 PID 1이 아닐 수 있습니다. (컨테이너 환경 등)

systemd의 탄생 배경과 필요성

과거 리눅스 시스템은 SysVinit 기반의 부팅 및 서비스 관리 방식을 사용했지만, SysVinit는 다음과 같은 문제점을 가지고 있었습니다.

 

1. 서비스의 병렬 실행 미지원 (부팅 속도가 느림)

2. 서비스 간 의존성 관리 부족

3. 서비스가 충돌할 경우 자동 복구 기능 미흡

4. 복잡한 스크립트 기반 서비스 관리 방식

 

이를 해결하기 위해 2010년 Lennart Poettering이 systemd를 개발하였고 systemd는 기존의 init 시스템을 거의 완벽하게 대체하는데 성공했습니다. systemd는 기존 시스템의 한계를 극복하면서도 강력한 기능을 제공하여 현대 리눅스 환경에서 표준으로 자리 잡게 되었습니다. 

 

systemd의 주요 특징은 아래와 같습니다.

 

1. 병렬 실행 지원으로 부팅 속도 개선

2. 유닛(Unit) 기반 서비스 관리

3. 소켓 기반 활성화로 필요할 때만 서비스 실행

4. 독립적인 로깅 시스템 (journald)

5. 런타임 및 전력 관리 기능 포함

---

2. systemd의 핵심 개념

유닛(Unit) 시스템 이해하기

systemd는 모든 시스템 리소스를 유닛(Unit) 개념으로 관리합니다. 각 유닛은 특정 역할을 수행하는 구성 요소이며, .service, .target, .socket 등의 형태로 존재합니다.

 

주요 유닛 종류

유닛	타입설명
.service	서비스 실행 및 관리
.target	특정 상태(런레벨) 그룹 관리
.socket	네트워크 소켓을 통한 서비스 실행
.timer	특정 시간에 서비스 실행 (Cron 대체 가능)
.mount	파일 시스템 마운트 자동화

유닛 파일의 구조

모든 유닛은 설정 파일을 통해 동작을 정의할 수 있습니다. 예를 들어, 아래와 같은 유닛 파일을 보면,

[Unit]
Description=My Custom Service
After=network.target
Requires=postgresql.service

[Service]
ExecStart=/usr/bin/myapp
Restart=always
User=myuser

[Install]
WantedBy=multi-user.target

이 설정은 네트워크가 활성화된 후 실행되며, postgresql.service가 필요하다는 의존성을 설정합니다.

유닛 파일의 저장 위치

• /etc/systemd/system/ (사용자 정의 유닛, 최우선 적용)
• /lib/systemd/system/ (배포판 기본 제공 유닛)
• /usr/lib/systemd/system/ (기본 설치된 서비스 유닛)

---

3. systemd의 동작 원리

병렬 실행과 의존성 관리

systemd는 기존의 SysVinit과 달리 서비스 및 프로세스를 병렬 실행하여 부팅 속도를 크게 개선했는데, 이전 SysVinit에서는 런레벨(runlevel) 개념을 사용해 특정 서비스가 종료된 후 다음 서비스를 실행하는 직렬(serial) 방식이었기 때문에 부팅 속도가 느렸습니다. 하지만 systemd는 서비스 간의 의존성을 분석하고, 가능한 한 병렬로 실행할 수 있도록 설계되었습니다.

프로세스 병렬 실행의 원리

systemd는 소켓 기반 활성화(socket-based activation), D-Bus 활성화(dbus-based activation), 자동 마운트(automounting) 등의 기능을 활용하여 부팅 시 서비스가 서로 기다리지 않고 독립적으로 실행될 수 있도록 구성합니다. 이를 통해 불필요한 지연 없이 서비스들이 최대한 빠르게 실행될 수 있습니다다.

의존성 관리와 실행 순서 제어

서비스 간 의존성은 유닛 파일(Unit File)을 통해 정의되는데, 각 유닛에는 After=, Requires=, Wants= 같은 속성을 사용하여 실행 순서를 지정할 수 있습니다.

의존성 설정 예제

[Unit]
Description=Web Application Service
After=network.target
Requires=database.service

• After=network.target → 네트워크가 활성화된 후 실행됨.
• Requires=database.service → database.service가 실행 중이어야 함.

위 설정을 통해 Web Application Service는 네트워크가 설정된 이후에 실행되며, database.service가 반드시 활성화된 상태여야 합니다. 만약 database.service가 실패하면, Web Application Service도 정상적으로 실행되지 않게 됩니다.

systemd의 이벤트 기반 실행 모델

systemd는 단순한 순차적 실행 방식이 아니라, 이벤트 기반(event-driven) 모델을 따릅니다. 예를 들어, 특정 서비스가 실행될 때 자동으로 다른 서비스를 시작하거나 특정 이벤트(파일 변경, 네트워크 상태 변화 등)에 따라 서비스가 실행되도록 할 수 있습니다.

이러한 방식은 서버 부팅 속도를 최적화하는 데 기여하며, 대형 시스템에서 복잡한 서비스 의존성을 보다 효과적으로 관리할 수 있도록 해줍니다.

---

4. systemd 명령어 정리

systemctl ?

systemctl은 systemd를 제어하는 명령어로, 시스템 서비스 및 유닛(Unit)을 관리하는 역할을 합니다.

systemctl 기본 사용법

서비스(Service) 관리

# 서비스 시작
sudo systemctl start <서비스명>

# 서비스 중지
sudo systemctl stop <서비스명>

# 서비스 재시작
sudo systemctl restart <서비스명>

서비스 상태 확인

sudo systemctl status <서비스명>

 

출력 예시:

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2025-02-19 14:02:41 UTC; 10min ago

서비스 활성화 및 비활성화 (부팅 시 자동 실행 설정)

# 자동 실행 활성화
sudo systemctl enable <서비스명>

# 자동 실행 비활성화
sudo systemctl disable <서비스명>

# 자동 실행 여부 확인
systemctl is-enabled <서비스명>

전체 서비스 목록 조회

systemctl list-units --type=service

특정 서비스가 실행 중인지 확인

systemctl is-active <서비스명>

특정 서비스가 설치되어 있는지 확인

systemctl list-unit-files | grep <서비스명>

---

5. 시스템 관련 명령어

시스템 재부팅 및 종료

# 시스템 종료
sudo systemctl poweroff

# 시스템 재부팅
sudo systemctl reboot

# 현재 런레벨 확인
systemctl get-default

시스템 런타임 상태 관리

# 현재 상태 확인
systemctl is-system-running

# 응급 모드 진입
sudo systemctl emergency

특정 프로세스 강제 종료

sudo systemctl kill <서비스명>

---

6. 로그 및 디버깅

systemd는 자체 로깅 시스템인 journald를 제공하며, journalctl 명령어를 사용해 강력한 로그 분석 기능을 지원합니다.

기본적인 로그 조회

# 전체 로그 조회
journalctl

# 부팅 후 로그 조회
journalctl -b

# 특정 서비스의 로그 조회
journalctl -u <서비스명>

# 특정 프로세스(PID)의 로그 조회
journalctl _PID=<PID>

시간 기준 로그 필터링

# 최근 1시간 동안의 로그 조회
journalctl --since "1 hour ago"

# 특정 날짜 이후의 로그 조회
journalctl --since "2024-02-01"

# 특정 날짜와 시간 범위의 로그 조회
journalctl --since "2024-02-01 12:00:00" --until "2024-02-01 14:00:00"

부팅 관련 로그

# 현재 부팅 로그 조회
journalctl -b

# 이전 부팅의 로그 조회
journalctl -b -1

# 모든 부팅 히스토리 조회
journalctl --list-boots

로그 출력 형식 조정

# 로그를 실시간으로 출력 (tail -f와 유사)
journalctl -f

# 로그를 JSON 형식으로 출력
journalctl -o json

사용자 기반 로그 조회

# 특정 사용자(ID)의 로그 조회
journalctl _UID=<사용자 ID>

저장된 로그 크기 및 관리

# 저장된 로그의 크기 확인
journalctl --disk-usage

# 로그를 500MB로 제한
sudo journalctl --vacuum-size=500M

# 7일 이상 된 로그 삭제
sudo journalctl --vacuum-time=7d

---

 

7. systemctl을 활용한 서비스 운영 예시

(1) Nginx 웹 서버 관리

sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

(2) 타이머 설정으로 자동 스크립트 실행

sudo nano /etc/systemd/system/myscript.timer

[Unit]
Description=Run my script every 10 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=10min

[Install]
WantedBy=timers.target

sudo systemctl enable myscript.timer
sudo systemctl start myscript.timer

(3) 특정 유닛 상태 모니터링 및 자동 복구

# 서비스 상태가 비정상일 경우 자동 재시작
sudo systemctl edit myservice.service

[Service]
Restart=always
RestartSec=5s

---

 

과거의 init 시스템은 복잡하고 비효율적인 구조로 인해 한계가 많았지만, systemd는 이를 해결하며 리눅스의 부팅과 서비스 관리를 근본적으로 변화시켰습니다.
현재 대부분의 주요 배포판에서 systemd는 운영 체제의 중심에서 모든 프로세스를 조율하는 필수적인 요소가 되었으며, PID 1의 자리를 차지하게 되었습니다.