[Linux] systemd 기반 시스템 운영에 필요한 필수 명령어

운영자는 장애 상황에서 즉시 근본 원인(root cause)을 찾을 수 있어야 한다.
전통적으로 top, ps, journalctl 등을 사용해 프로세스의 상태를 점검했지만, systemd 기반 시스템에서는 이런 접근법으로는 명확한 원인을 찾기 어렵다.

systemd는 모든 서비스를 유닛으로 추상화하여 관리하며, 프로세스와 자원을 CGroup(Control Group)이라는 커널 메커니즘을 통해 관리한다. 따라서 systemd 시스템을 다룰 때는 이 구조를 이해하고 활용해야 한다.

systemctl

---

서비스의 상태를 확인할 수 있는 도구다.

실패한 서비스 전체 조회

$ systemctl --failed

UNIT               LOAD   ACTIVE SUB    DESCRIPTION
docker.service     loaded failed failed Docker Application Container Engine
nginx.service      loaded failed failed A high performance web server

2 loaded units listed.

 

현재 시스템에서 실패(failed) 상태에 빠진 모든 서비스를 즉시 확인할 수 있다. 프로세스 단위로는 보이지 않는 서비스의 문제를 서비스 단위로 한눈에 파악할 수 있으며, 서비스가 언제, 왜 실패했는지 로그를 통해서도 즉각적으로 확인 가능하다.

특정 서비스 상세 상태 조회

$ systemctl status nginx

● nginx.service - A high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2025-07-27 15:10:42 KST; 2min ago
  Process: 4321 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
 Main PID: 4321 (code=exited, status=1/FAILURE)

Jul 27 15:10:42 localhost systemd[1]: Failed to start A high performance web server.
Jul 27 15:10:42 localhost systemd[1]: nginx.service: Failed with result 'exit-code'.

이 명령어 하나로 서비스가 어떤 상태인지 정확히 알 수 있다. 상태, PID, 종료 코드(Exit Code), 최근 로그까지 즉시 제공된다.

• Main PID: 서비스의 메인 프로세스 ID, 현재 살아있는지 확인 가능.
• Exit Code: 프로세스가 어떤 이유로 종료됐는지 정확히 알려줌.
• 최근 로그: 서비스가 종료 직전의 로그를 통해 장애 원인을 확인 가능.
• Restart 상태: 반복적 종료 시 자동 재시작 여부 파악 가능.

부팅 시 자동 실행 여부 확인

$ systemctl is-enabled <서비스명>

enabled 또는 disabled

 

서비스가 부팅 후 자동으로 실행되지 않는다면 이 명령부터 확인해야 한다. Unit 파일이 존재하더라도 상태가 enabled가 아니면 자동 실행되지 않는다.

systemd-cgls 

---

서비스가 실행한 프로세스가 어떤 구조로 작동하는지 시각적으로 보여주는 도구다.

• Zombie 프로세스가 어느 서비스에서 나왔는지 즉시 확인 가능.
• 특정 프로세스가 정확히 어떤 서비스나 컨테이너에서 실행됐는지 시각적으로 파악 가능.
• 리소스를 과다 점유하는 유저 세션도 빠르게 찾을 수 있음.

$ systemd-cgls

/sys/fs/cgroup
├─system.slice
│ ├─nginx.service
│ │ ├─1212 nginx: master process
│ │ └─1220 nginx: worker process
│ └─docker.service
│   └─containerd.scope
│     └─5678 container process
├─user.slice
│ └─user-1000.slice
│   └─session-3.scope
│     ├─2342 bash
│     └─2456 vim

 

systemd-cgtop

---

top이나 htop 같은 기존 도구는 프로세스 단위만을 표시한다.  systemd-cgtop은 서비스 단위로 실제 리소스를 점유하는 주체를 확인할 수 있다.

• 프로세스가 아니라 서비스 단위로 리소스를 명확히 측정 가능.
• Docker 컨테이너(docker-abc123.scope)별로도 리소스 점유를 바로 확인 가능.
• 유저 세션 단위(user-1000.slice)로 자원 낭비 확인 가능.
• 특정 컨테이너의 IO 폭주를 즉시 발견 가능.
• CPU를 과도하게 사용하는 서비스 식별 후 성능 튜닝 가능.
• 메모리 누수의 근원을 정확히 잡아낼 수 있음.

$ systemd-cgtop

UNIT              CPU   MEMORY    IO       TASKS
docker.service    42%   1.5GiB    4.5MB/s  72
nginx.service     18%   250MiB    100kB/s  8
user-1000.slice   12%   620MiB    1MB/s    89

 

systemd-analyze

---

systemd-analyze는 systemd 기반 시스템의 부팅 시간 분석, 서비스 초기화 병목 지점 파악, 유닛 간 의존 관계 시각화 등에 사용된다. 단순한 부팅 시간 확인부터 복잡한 성능 튜닝까지 다양하게 활용된다.

부팅 시간 전체 요약

$ systemd-analyze

Startup finished in 2.432s (kernel) + 3.821s (userspace) = 6.253s graphical.target reached after 3.782s in userspace

• kernel: 커널 초기화 시간
• userspace: systemd 유닛 실행 포함, 전체 사용자 영역 초기화 시간
• total: 전체 부팅 시간 (이 수치가 체감 부팅속도와 직결)

서비스별 부팅 지연 시간 정렬 보기

$ systemd-analyze blame

5.321s docker.service
2.011s NetworkManager-wait-online.service
1.221s dev-sda1.device

• systemd는 서비스 병렬 실행을 시도하지만, 일부 서비스는 종속성 때문에 대기하게 된다.
• 이 명령은 어떤 유닛이 부팅을 지연시키는지 정확히 보여준다.

유닛 간 의존 관계 시각화 (dot 그래프)

systemd-analyze plot > boot.svg

• 결과는 SVG 형식의 시각적 부팅 타이밍 그래프이며, 각 서비스가 언제 시작됐는지 시간 축 기준으로 표현됨.
• 성능 최적화나 병목 진단 시 필수적으로 사용되는 시각화 도구.

유닛의 의존 트리 분석

$ systemd-analyze critical-chain

graphical.target @3.782s
└─multi-user.target @3.782s
  └─docker.service @1.432s +2.345s
    └─network-online.target @1.321s
      └─NetworkManager-wait-online.service @0.912s +0.409s

• critical-chain은 부팅 시 실행 순서 상 가장 긴 지연 경로(병목 체인)를 보여준다.
• 서비스 간의 의존성 관계를 시간 순으로 분석하여, 어느 단계가 전체 부팅을 지연시키는지 분석 가능.