*.journal
Ubuntu 18.04 호스트 중 하나가 예상보다 훨씬 많은 12GB의 파일로 캡처되었습니다 . 보관할 가치가 있는지 알아보기 위해 나는 달렸습니다.
journalctl --file $f
오늘보다 오래된 모든 파일은 항상 Failed to open files
또는 --- No entries ---
.
그러한 파일은 쓰레기이므로 폐기할 수 있다고 결론을 내리는 것이 맞습니까?
그렇다면 존재하는 이유는 무엇입니까? 이를 정리하기 위해 지원되는 방법은 무엇입니까? 시스템의 존재 여부를 정기적으로 확인하는 것이 가치가 있습니까?
답변1
우선 저널은 로깅 시스템이며 systemd
무슨 일이 일어났는지 알아야 할 때 그 존재가 중요합니다.
말한 바와 같이여기, journalctl --file
그거 쓸만하지 않나요?
저널 파일은 주기적으로 교체되므로 이 양식은 전체 저널을 보는 데 실제로 사용할 수 없습니다.
이제 파일이 쓸모없다고 생각하는지 여부는 사용자가 결정합니다. 일반적으로 너무 오래된 로그는 보관할 가치가 없으므로 삭제할 수 있습니다.
그렇게 하려면 journalctl
그 자체와 유틸리티 진공을 사용하는 것이 가장 좋습니다. 예를 들어 다음을 사용할 수 있습니다.
sudo journalctl --vacuum-time=3weeks
3주가 넘은 모든 저널 파일을 삭제하려면
자세한 내용은 다음을 확인하세요.매뉴얼 페이지와 함께 man journalctl
.
--vacuum-size=, --vacuum-time=, --vacuum-files=
사용하는 디스크 공간이 지정된 크기(일반적으로 "K", "M", "G" 및 "T" 접미사로 지정) 아래로 떨어지거나 모든 아카이브된 저널 파일에 다음보다 오래된 데이터가 포함되지 않을 때까지 가장 오래된 아카이브된 저널 파일을 제거합니다. 지정된 시간 범위(일반적인 "s", "m", "h", "일", "월", "주" 및 "년" 접미사로 지정됨) 또는 지정된 개수 이하의 개별 저널 파일이 남아 있습니다. --vacuum-size=를 실행하면 --disk-usage에 표시된 출력에 간접적인 영향만 미치는데, 후자는 활성 저널 파일을 포함하는 반면, 진공 작업은 아카이브된 저널 파일에서만 작동합니다. -files=는 활성 저널 파일을 제거하지 않으므로 실제로 저널 파일 수를 지정된 수 미만으로 줄이지 않을 수 있습니다.
또한 이것을 주기적으로 확인하는 것이 가치가 없다고 생각합니다. 에서 다음 항목의 주석 처리를 제거하고 변경하여 상한을 설정하는 것입니다 /etc/systemd/journald.conf
.
예를 들어:
SystemMaxUse=4G
그런 다음 서비스를 다시 시작하십시오 sudo systemctl restart systemd-journald
.
더 많은 정보를 위해 사용하세요 man journald.conf
.
편집하다:
@reinierpost의 설명대로
이 질문은 일반적인 오래된 로그에 관한 것이 아니라 로그가 전혀 포함되어 있지 않은 것처럼 보이는 오래된 로그 파일에 관한 것입니다(그러나 여전히 각 로그 파일은 8MB를 차지합니다).
을 실행해 보세요 journalctl --verify
. 파일이 통과하지 못하면 저널이 손상된 것이므로 서비스를 다시 시작해야 합니다.
sudo systemctl restart systemd-journald
그러면 앞으로 로그에 대한 문제가 해결될 것입니다.
처음에 왜 이런 일이 발생했는지는 알 수 없고 알아내기도 쉽지 않습니다. 손상된 파일은 아마도 정크일 것입니다.이것깨끗한 슬레이트를 위해.
답변2
비슷한 일이 발생했습니다. Ubuntu 22.04 시스템 중 하나에는 /var/log/journal
3년 전의 파일이 81G 있었습니다. journalctl --utc --no-pager | head
내 파일은 약 6일 전의 것으로 나타났습니다. journald.conf
다른 VM을 확인하기 시작했습니다. 비슷한 문제를 발견했습니다.
나는 시도했다:
SystemMaxUse=10G
systemd-journald 설정 및 다시 시작RuntimeMaxUse=10G
systemd-journald 설정 및 다시 시작- SystemMaxFiles=30으로 설정
SystemMaxFileSize=1G
하고 systemd-journald를 다시 시작하세요. MaxFileSec=1month
systemd-journald 설정 및 다시 시작
이러한 설정 중 어느 것도 이전 로그 파일을 제거하지 않았습니다 /var/log/journal
. 나는 또한 다음을 시도했습니다.
journalctl --flush --rotate
journalctl --rotate --vacuum-time=10days
기존 파일은 모두 그대로 남아 있습니다.
journalctl --disk-usage
저널링된 청구는 496M만 사용합니다.
journalctl --verify
모든 확인은 "통과"로 표시되지만 확인만 표시됩니다 /var/log/journal
. 다른 모든 디렉터리는 저널링에 의해 고아가 되었다고 가정하지만 현재 날짜까지 유지되므로 이는 지속적인 문제입니다.
로그에서 삭제했어야 했지만 삭제하지 않은 정크를 제거하기 MaxFileSec=1month
위해 일일 크론 작업을 설정하고(기본값이어야 함) 추가하여 문제를 해결 했습니다 .find /var/log/journal -mtime +45 -delete