대상 OS: Ubuntu Server 24.04 LTS

systemd-journald는 서버 운영에서 매우 중요한 로그 소스입니다. 그런데 운영 현장에서는 다음 두 종류의 사고가 반복됩니다.

  • 영속화(디스크 저장)를 안 해서 재부팅/장애 이후 로그가 날아가 원인 분석이 어려움
  • 영속화만 해두고 용량 제한을 안 해서 디스크가 로그로 잠식되어 서비스 장애로 이어짐

즉, Storage=persistent와 용량 제한(SystemMaxUse 등)은 세트로 잡아야 “보안/운영” 둘 다 안전합니다.

1) 현재 journald 저장 방식과 사용량 확인

# journald 디스크 사용량
journalctl --disk-usage

# 현재 설정값 확인(실제 적용값)
systemd-analyze cat-config systemd/journald.conf | sed -n '1,200p'

2) 영속화 + 용량 제한(권장 예시)

Ubuntu에서 영속화를 쓰려면 보통 /var/log/journal 디렉터리가 있어야 합니다(없으면 runtime 저장으로 동작할 수 있음).

  1. 영속화 디렉터리 준비

    sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal


  2. 설정 파일 편집

    sudoedit /etc/systemd/journald.conf


  3. 권장 설정(예시)

    [Journal]
Storage=persistent

# journald가 사용할 최대 디스크(서버 크기에 맞게 조정)
SystemMaxUse=1G

# 단일 파일 상한(큰 파일로 비대해지는 것 방지)
SystemMaxFileSize=128M

# 디스크가 부족할 때 journald가 최소로 남길 공간(안전장치)
SystemKeepFree=1G

# 과도한 플러시/성능 이슈가 있다면 조정(기본값을 보통 유지)
# SyncIntervalSec=5m


  4. 적용(재시작) 및 확인

    sudo systemctl restart systemd-journald
journalctl --disk-usage


3) 보안 관점에서의 의미(왜 이게 ‘보안’인가)

  • 증거 보존: 인증 실패, 권한 상승 흔적, 서비스 크래시 직전 로그는 침해사고/장애 분석의 핵심 증거입니다.
  • 로그 기반 탐지: fail2ban, SIEM, 원격 로그 전송 등은 로컬 로그가 안정적으로 유지되어야 효과가 있습니다.
  • 자원 고갈 공격 완화: 로그 폭증으로 디스크를 채우는 형태(간접 DoS)를 제한 설정으로 완화할 수 있습니다.

4) 사례(현장에서 자주 겪는 상황)

  • “재부팅 이후 직전 장애 로그가 없어 원인을 못 찾음”: Storage가 volatile이거나 /var/log/journal이 없어 휘발성으로 동작한 케이스. 영속화 디렉터리부터 확인합니다.
  • “/var가 가득 차서 서비스가 멈춤”: journald가 장기간 누적되며 디스크를 잠식. SystemMaxUse/SystemKeepFree로 상한을 잡고, 별도 로그 보관은 원격 전송으로 해결합니다.
  • “로그 보관 정책 때문에 특정 기간 이상 남기면 안 됨”: journald 용량 기반 정책만으로는 기간 보장이 어렵습니다. 필요 시 원격 전송/중앙 저장소에서 기간 정책을 적용합니다.

5) 트러블슈팅(증상→원인→해결)

  • 증상: Storage=persistent로 설정했는데도 재부팅 후 로그가 짧게만 남음
    원인: /var/log/journal 미생성, 권한/디스크 마운트 이슈
    해결: ls -ld /var/log/journal 확인, 디렉터리 생성 후 journald 재시작
  • 증상: 설정했는데도 disk-usage가 계속 증가
    원인: 설정이 주석/오타로 적용되지 않음, 또는 다른 설정 파일 우선순위
    해결: systemd-analyze cat-config systemd/journald.conf로 실제 적용값 확인 후 수정
  • 증상: journald 재시작 후 특정 서비스 로그가 안 보임
    원인: 로그 레벨/서비스 출력 방식 변화, rate limit 영향
    해결: journalctl -u 서비스명 -n 200 --no-pager로 단위별 확인, 필요 시 rate limit 옵션 검토

root.so · Linux/Security 운영 노트

journald는 “남기기(영속화)”와 “넘치지 않게(용량 제한)”를 동시에 해야 운영과 보안 둘 다 안전합니다.