Linux 강좌 / systemd 서비스와 부팅 로그 확인하기

systemd를 사용하는 리눅스에서 부팅은 펌웨어와 부트로더를 거쳐 커널이 시작된 뒤, 시스템 관리자인 systemd가 서비스와 다른 유닛을 활성화하는 흐름입니다. 서비스 문제를 확인할 때는 systemctl로 현재 상태와 부팅 시 활성화 설정을 각각 보고, journalctl로 같은 부팅의 로그를 읽으세요. 이 두 상태는 서로 다릅니다.

부팅 흐름을 큰 단계로 이해하기

일반적인 PC·서버 부팅은 펌웨어가 하드웨어를 초기화하고 부트로더를 찾는 것으로 시작합니다. 부트로더는 커널과 필요한 초기 환경을 로드하고, 커널은 장치·메모리·프로세스 실행 기반을 준비합니다. 그다음 첫 사용자 공간 프로세스인 초기화 시스템이 서비스 등을 관리합니다. 여기서는 systemd가 PID 1인 배포판을 대상으로 합니다. 다른 초기화 시스템을 쓰는 환경에는 명령과 절차가 다를 수 있습니다.

ps -p 1 -o pid,comm,args
systemctl get-default

첫 명령의 COMMAND 또는 ARGS에서 PID 1이 systemd인지 확인하세요. 컨테이너나 특수 환경에서는 다를 수 있습니다. 두 번째 명령은 기본 target을 보여 줍니다. 예를 들어 multi-user.target은 일반적인 다중 사용자 텍스트 환경의 목표이고, graphical.target은 그래픽 환경의 목표일 수 있습니다. target은 여러 유닛을 묶는 목표이며, 모든 서비스가 한 줄로 순차 시작된다는 뜻은 아닙니다.

systemd 유닛과 의존 관계

systemd는 관리 대상을 유닛(unit)으로 표현합니다. .service는 서비스, .target은 여러 유닛을 묶는 목표, .socket은 소켓 기반 활성화, .timer는 시간 기반 실행과 관련됩니다. 서비스를 사용하려면 해당 프로그램 패키지와 유닛이 실제로 설치돼 있어야 합니다. 이름을 추측해서 운영 서버의 서비스를 시작하거나 중지하지 마세요.

서비스 시작 순서는 단순한 숫자 순서가 아니라 유닛 간 의존성과 순서 규칙에 따라 결정됩니다. 어떤 유닛이 다른 유닛 뒤에 시작되도록 설정돼 있어도, 그것만으로 필요 관계까지 생기는 것은 아닙니다. 부팅 중 일부 유닛은 병렬로 실행되므로 느린 부팅을 조사할 때 목록의 위아래만으로 원인을 확정할 수 없습니다.

systemctl list-units --type=service --state=running
systemctl --failed

첫 명령은 현재 로드된 실행 중 서비스 유닛을, 두 번째는 실패 상태의 유닛을 보여 줍니다. 실패 목록이 비어 있어도 애플리케이션이 올바르게 응답하는지까지 보장하지는 않습니다. 포트·응답·애플리케이션 로그를 별도로 확인해야 할 수 있습니다.

실행 상태와 자동 시작 설정의 차이

active는 지금 실행 또는 활성 상태인지와 관련되고, enabled는 보통 관련 target에 연결돼 부팅 시 시작하도록 설정됐는지를 뜻합니다. 지금 active인 서비스가 disabled일 수 있고, enabled여도 현재 시작에 실패했을 수 있습니다. static 유닛은 별도의 설치 규칙이 없어 직접 enable하지 못해도 다른 유닛의 의존성 등으로 동작할 수 있습니다.

표의 NAME.service는 자리표시자이며 실제 설치된 유닛 이름으로 바꿔야 합니다. 서버에 접속하는 데 쓰는 SSH 서비스 같은 필수 유닛을 멈추면 원격 접속이 끊어질 수 있습니다. 변경 명령은 서비스 영향·복구 경로를 확인한 후에만 실행하세요.

읽기 전용 명령으로 서비스 살펴보기

다음의 systemd-journald.service는 systemd 환경에서 자주 볼 수 있는 유닛이지만 최소 이미지나 특수 환경에서는 결과가 다를 수 있습니다. 모두 조회 명령입니다.

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status는 로드 정보, 현재 상태, 실행 프로세스와 최근 로그 일부를 보여 줄 수 있습니다. is-active는 active, inactive, failed 등의 결과를 출력하고 비활성 상태에서 0이 아닌 종료 상태를 반환할 수 있습니다. is-enabled는 enabled뿐 아니라 disabled, static 등도 표시할 수 있습니다. static을 곧바로 오류라고 판단하지 마세요.

서비스를 바꿀 때 알아둘 명령

실제로 변경할 때 start와 stop은 지금의 상태에, enable과 disable은 자동 시작 설정에 각각 초점을 둡니다. restart는 일단 서비스를 다시 시작하므로 연결이 끊어지거나 작업이 중단될 수 있습니다. reload는 서비스가 지원할 때만 설정을 다시 읽도록 요청하며, 동작 여부와 범위는 서비스별로 다릅니다. enable --now는 자동 시작 설정과 즉시 시작을 함께 요청합니다.

유닛 파일 자체를 만들거나 수정한 뒤에는 systemd 관리자가 정의를 다시 읽도록 daemon-reload가 필요할 수 있습니다. 이는 애플리케이션 프로세스를 다시 시작하는 restart나 애플리케이션 설정을 다시 읽는 reload와 다릅니다. 운영 중인 서비스의 유닛·설정 변경에는 먼저 백업과 유지보수 창을 마련하세요.

journalctl로 현재 부팅의 로그 읽기

systemd 저널에는 서비스와 커널 등 여러 출처의 로그가 모일 수 있습니다. -b는 현재 부팅으로 범위를 좁히고, -u는 지정한 유닛의 메시지만 선택합니다. -n 30은 최근 30개 항목을 요청합니다. 조회 권한이 부족하면 일부 로그가 보이지 않을 수 있으며, 그때는 허용된 관리자 계정이나 적절한 권한으로 다시 확인해야 합니다.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

첫 명령은 현재 부팅에서 해당 유닛의 최근 기록, 둘째는 경고 이상 우선순위의 최근 기록을 보여 줍니다. 경고 한 줄이 곧 장애 원인이라는 뜻은 아니며 발생 시각과 앞뒤 문맥을 함께 읽어야 합니다. --list-boots에 이전 부팅이 없다면 저널 보존 설정이나 저장 공간 정책 때문에 과거 로그를 사용할 수 없는 것일 수 있습니다. 이전 부팅을 조사할 때는 기록이 실제로 있는지 먼저 확인하세요.

서비스가 시작되지 않을 때 진단 순서

1. 문제가 난 유닛의 정확한 이름과 패키지 설치 여부를 확인합니다. 비슷한 이름의 다른 서비스를 추측해 조작하지 않습니다.
2. systemctl status로 loaded, active, 실패 이유의 요약과 최근 기록을 확인합니다.
3. journalctl -b -u로 같은 부팅의 해당 유닛 로그를 더 넓게 읽습니다. 설정 오류, 권한 문제, 포트 충돌, 의존 서비스 실패처럼 실제 메시지가 가리키는 원인을 찾습니다.
4. 설정 파일과 필요한 자원·의존 관계를 확인하고, 변경 전 백업을 남깁니다. 로그의 한 줄만 보고 권한을 과도하게 풀지 않습니다.
5. 원인을 고친 뒤 서비스 영향이 허용되는 시점에 필요한 동작만 수행하고 is-active 및 실제 애플리케이션 응답을 확인합니다.

부팅 시간이 문제라면 systemd-analyze critical-chain은 중요한 시작 경로를 살펴보는 데 도움이 됩니다. 반면 systemd-analyze blame의 개별 시간이 길다는 이유만으로 그 서비스가 전체 부팅 지연의 원인이라고 단정해서는 안 됩니다. 병렬 실행과 의존 관계를 함께 해석해야 합니다.

공식 문서

systemctl(1) 매뉴얼은 유닛 상태와 변경 명령을, journalctl(1) 매뉴얼은 부팅·유닛·우선순위별 로그 조회를 설명합니다. systemd.unit(5) 매뉴얼에서 유닛과 의존 관계의 자세한 의미를 확인할 수 있습니다.