Linux journalctl 로그 정리, 디스크 부족을 안전하게 줄이는 순서

AI를 활용하여 생성한 이미지입니다.

Linux에서 디스크가 갑자기 줄어들면 오래된 로그부터 지우고 싶은 마음이 들어요. 하지만 journalctl --vacuum-size만 바로 실행하면 현재 사용량이 기대만큼 줄지 않을 수 있습니다. systemd journal은 활성 파일과 보관된 파일을 함께 관리하고, vacuum은 보관된 파일을 대상으로 동작하기 때문이에요.[1]

먼저 로그가 어디에 쌓이는지 확인해요

현재 journal이 차지하는 공간은 다음 명령으로 확인할 수 있어요.

journalctl --disk-usage
journalctl --list-boots

--disk-usage는 활성 파일과 보관된 journal 파일을 합산해 보여줘요. 그래서 vacuum 직후에도 숫자가 그대로라면 명령이 실패했다고 단정하지 말고, 활성 파일이 아직 남아 있는지 확인해야 합니다.[1]

휘발성 로그와 영구 로그를 구분해요

systemd-journald는 설정과 디렉터리 상태에 따라 로그를 /run/log/journal에 임시로 두거나 /var/log/journal에 영구 보관할 수 있어요. journald 설정에서 Runtime* 항목은 휘발성 저장소, System* 항목은 영구 저장소에 적용됩니다.[2]

장애가 재부팅 뒤에 재현되는 문제라면 영구 로그가 유용합니다. 반대로 컨테이너나 테스트 VM처럼 매번 새로 시작하는 환경에서는 로그를 오래 보관할 이유가 적을 수 있어요. 보존 기간은 “많을수록 좋다”가 아니라 장애 조사 기간과 디스크 크기를 함께 보고 정해야 합니다.

삭제 전에 증거를 남겨요

1. 장애가 시작된 날짜와 서비스 이름을 기록합니다.
2. journalctl -u 서비스이름 --since "7 days ago"처럼 필요한 범위의 로그를 별도 파일로 내보냅니다.
3. 부팅 직후 문제가 있다면 journalctl -b -1로 이전 부팅을 확인합니다.
4. 보안·인증·스토리지 장애처럼 재현이 어려운 문제는 보존 기간을 줄이기 전에 운영 기록을 남깁니다.

journalctl은 로그를 백업·전송할 수 있는 export 형식도 제공해요. 전체 로그를 무조건 보관하기보다, 조사에 필요한 서비스와 시간 범위를 먼저 저장하는 편이 관리하기 쉽습니다.[1]

vacuum은 rotate 뒤에 실행해요

보관된 파일만 정리하려면 다음처럼 기간이나 크기를 기준으로 실행할 수 있어요.

sudo journalctl --rotate
sudo journalctl --vacuum-time=14days
# 또는
sudo journalctl --vacuum-size=1G

--vacuum-time, --vacuum-size, --vacuum-files는 함께 사용할 수 있고, 보관된 journal 파일에 적용됩니다. 먼저 --rotate로 현재 파일을 보관 상태로 넘긴 뒤 vacuum하면 결과를 확인하기 쉬워요.[1] 단, 무조건 1G로 맞추면 오래된 장애 분석 자료가 사라질 수 있으니 운영 환경의 최소 보존 기간을 먼저 정하세요.

보존 정책은 drop-in으로 관리해요

설정 파일을 직접 크게 고치기보다 /etc/systemd/journald.conf.d/ 아래에 목적이 드러나는 drop-in 파일을 두는 방법이 안전합니다. 예를 들어 보관 기간과 최대 사용량을 정책으로 관리하려면 다음처럼 시작할 수 있어요.

[Journal]
SystemMaxUse=1G
MaxRetentionSec=14day

실제 값은 디스크 크기, 장애 대응 기간, 로그에 포함되는 개인정보 여부를 보고 정해야 합니다. 설정 파일 위치와 System*, Runtime*의 적용 대상은 journald 매뉴얼에서 확인할 수 있어요.[2] 변경 뒤에는 sudo systemctl restart systemd-journald를 서둘러 실행하기보다, 배포판의 적용 방식과 현재 로그 기록 상태를 먼저 확인하세요.

WSL에서는 systemd부터 확인해요

WSL 배포판은 모두 같은 초기화 구성을 쓰지 않아요. Microsoft는 WSL에서 systemd를 사용할 수 있고, 활성화한 뒤 systemctl status와 서비스 목록으로 동작 상태를 확인하도록 안내합니다.[3] 따라서 WSL에서 journalctl 결과가 비어 있으면 vacuum 문제로 단정하지 말고 systemd가 실행 중인지부터 보세요.

• systemctl status로 systemd 실행 여부를 확인하기
• journalctl -b 0으로 현재 세션 로그 범위 확인하기
• journalctl --disk-usage로 실제 사용량 확인하기
• 필요한 로그를 export하거나 파일로 저장한 뒤 rotate·vacuum 실행하기
• 보존 정책을 바꾼 뒤 다음 재부팅과 장애 재현 시 로그가 남는지 확인하기

WSL 네트워크나 localhost 연결 문제를 함께 보고 있다면 WSL2 NAT·미러드 네트워킹과 VPN·localhost 점검법도 연결해서 확인해 보세요.

증상별로 범위를 좁히는 명령

로그가 많다는 이유만으로 전부 줄이지 말고, 장애와 관련된 부팅·우선순위·서비스를 먼저 좁혀 보세요. 예를 들어 부팅 실패 원인을 볼 때는 journalctl -b -1 -p err로 이전 부팅의 오류 우선순위를 확인하고, 특정 시간대는 --since와 --until로 잘라서 비교할 수 있어요. 서비스가 재시작됐는지 보고 싶다면 journalctl -u 서비스이름 --since yesterday가 더 유용합니다.[1]

이렇게 필요한 기록을 보관한 뒤에야 전체 정책을 조정하세요. --vacuum-files는 파일 개수를 기준으로 줄이는 방식이고, 날짜 기준 정리가 필요하면 --vacuum-time이 더 분명합니다. 여러 기준을 함께 쓸 때는 가장 보수적인 조건이 실제 결과를 결정할 수 있으니, 명령을 한 번에 크게 적용하지 말고 전후 --disk-usage를 기록하는 편이 좋아요.[1]

정리 뒤에 확인할 항목

정책을 적용한 뒤에는 로그가 실제로 필요한 기간만 남기는지 확인하고, 서비스가 재시작될 때 새 로그가 기록되는지도 봐야 해요. journalctl -u 서비스이름 --since today처럼 서비스 단위로 조회하면 전체 로그를 다시 훑지 않아도 됩니다. 디스크가 가득 찬 원인이 journal이 아니라 애플리케이션 로그, 컨테이너 레이어, 패키지 캐시라면 journal 정책만 바꿔도 해결되지 않아요. du나 배포판의 디스크 분석 도구로 상위 사용 경로를 따로 비교하세요.

운영 서버에서는 보존 기간을 너무 짧게 잡기보다 장애 대응에 필요한 기간을 먼저 정하고, 그 안에서 최대 크기를 계산하는 방식이 좋아요. 테스트 환경이라면 짧은 기간과 작은 크기로 시작해도 되지만, 설정 변경 후에는 다음 부팅과 서비스 장애 상황에서 조회가 가능한지 확인해야 합니다.

Sources

• [1] freedesktop.org, journalctl 매뉴얼
• [2] freedesktop.org, journald.conf 매뉴얼
• [3] Microsoft Learn, WSL에서 systemd 사용