결론: 작은 CasaOS 시스템 디스크가 가득 차기 전에 journald 사용량을 제한하세요
기존 CasaOS 시스템에는 다음 경로 아래에 5GB가 넘는 데이터가 있었습니다: /var/log/journal. 확실한 해결책은 journal 파일을 직접 삭제하는 것이 아닙니다. 크기 상한을 설정하고, 필요하면 최소 여유 공간을 유지하도록 지정한 뒤, 보관된 오래된 로그를 한 번 Vacuum하세요. 그러면 이후 journald가 정책을 자동으로 적용합니다.
변경하기 전에 journal 사용량 측정
journalctl --disk-usage
du -sh /var/log/journal 2>/dev/null
df -h /var로그가 작은 부팅 디스크에서 수 기가바이트를 차지하고 있다면 실제로 얼마나 최근 기록이 필요한지 결정하세요. 홈 서버에서는 기본값이 파일 시스템의 일정 비율을 차지하도록 두는 것보다 고정 상한을 설정하는 편이 일반적으로 더 예측하기 쉽습니다.
journald.conf에서 크기 및 보존 제한 설정
[Journal]
SystemMaxUse=1G
SystemKeepFree=1G
MaxRetentionSec=14daySystemMaxUse는 영구 journal 저장 공간을 제한하고, SystemKeepFree는 운영 체제의 나머지 부분을 위해 여유 공간을 보존합니다. 시간 기준 상한도 원한다면 MaxRetentionSec를 선택적으로 사용할 수 있습니다. 이러한 제한의 상호 작용 방식은 journald 크기 제한에 설명되어 있습니다.
정책을 설정한 후 오래된 로그를 한 번만 Vacuum하세요
sudo journalctl --rotate
sudo journalctl --vacuum-size=1GVacuum은 보관된 journal 파일을 제거할 뿐 설정을 대체하지는 않습니다. Vacuum만 수행하고 제한을 설정하지 않으면 디렉터리가 다시 커질 수 있습니다. journalctl vacuum 제어에서 지원되는 정리 명령을 확인할 수 있습니다.
설정 파일을 교체하기 위해 journald를 중지하지 마세요
2024년 게시글에서는 서비스를 중지하고 설정 파일을 삭제한 다음 대체 파일을 복사했습니다. 이 방법도 작동하지만 필요 이상으로 중단이 큽니다. 파일을 안전하게 편집하고 백업을 유지한 후 서비스를 다시 시작하세요:
sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo nano /etc/systemd/journald.conf
sudo systemctl restart systemd-journaldjournald가 다른 디스크에 로그를 저장할 수 있나요?
의 단순한 임의 경로를 통해서는 안 됩니다 journald.conf. Storage=persistent 대상 /var/log/journal; Storage=volatile 사용 /run/log/journal. 다른 곳에서 더 오래 보관해야 한다면 중요한 시스템 경로를 무심코 바인드 마운트하는 대신 로그를 다른 syslog/journal 호스트로 전달하세요.
과도한 로그를 생성하는 서비스 찾기
journalctl -p warning..alert --since "24 hours ago"
journalctl --since "24 hours ago" | tail -200
systemctl --failed디스크 한도는 OS를 보호하지만 동일한 오류를 수천 번 기록하는 서비스 문제를 해결하지는 못합니다. 시스템에 여유 공간이 생기면 로그를 과도하게 생성하는 서비스를 수정하세요.
기존 CasaOS 설치에서 보다 어플라이언스형 서버로 이전하려는 경우, ZimaBoard 2 플랫폼과 ZimaOS 백업은 보다 안전한 마이그레이션 환경을 제공합니다.
특정 서비스가 저널에 로그를 과도하게 생성하지 않도록 하기
하나의 컨테이너나 데몬이 동일한 경고를 계속 출력한다면, 전역 저장 공간 제한은 피해를 제한할 뿐입니다. 가장 많은 로그를 생성하는 유닛을 확인한 다음 원인을 해결하세요.
journalctl --since "1 hour ago" -o short-unix | tail -500
journalctl -u SERVICE_NAME --since "1 hour ago"systemd에서 관리하는 서비스의 경우, 유닛별 로그 속도 제어를 사용하면 다른 시스템 로그를 모두 버리지 않고도 급격한 로그 증가를 줄일 수 있습니다. 무엇이 억제되는지 파악한 후에만 속도 제한을 사용하세요. 반복되는 저장소, 파일 시스템 또는 네트워크 오류가 근본 문제를 해결하는 데 필요한 단서일 수 있습니다.
FAQ
SystemMaxUse는 얼마나 크게 설정해야 하나요?
보편적으로 적용되는 값은 없습니다. 작은 OS 디스크에서 긴 로그 기록이 거의 필요하지 않다면 500MB~2GB부터 시작하는 것이 실용적입니다. 업데이트와 애플리케이션 메타데이터를 위한 여유 공간을 충분히 남겨 두세요.
journalctl --vacuum-size를 사용하면 현재 로그도 삭제되나요?
목표 크기에 도달할 때까지 보관된 저널 파일을 삭제합니다. 활성 저널을 보관된 파일 집합으로 옮기려면 먼저 로테이션하세요.
/var/log/journal에 logrotate를 사용해야 하나요?
아니요. 바이너리 저널 파일은 systemd-journald 자체에서 관리합니다. journald 크기 및 보존 설정과 journalctl 정리 작업을 사용하세요.
로그를 다른 HDD에 보관할 수 있나요?
로그 전달이나 의도적으로 설계된 마운트를 통해서는 가능합니다. 하지만 journald는 임의의 사용자 지정 경로 설정을 제공하지 않습니다. 핵심 OS 디렉터리를 옮기는 것보다 원격 로깅이 일반적으로 더 안전합니다.
저널이 왜 수 기가바이트까지 늘어났나요?
기본 정책에서는 상당한 저장 공간이 허용될 수 있으며, 로그를 과도하게 생성하는 서비스 하나가 항목을 빠르게 늘릴 수 있습니다. 설정된 한도와 로그를 많이 생성하는 서비스를 모두 확인하세요.
