☰

如何检测和清理垃圾日志文件？

tag-icon • tag-icon systemd-journald journalctl
如何检测和清理垃圾日志文件？

我们的一台 Ubuntu 18.04 主机被捕获了 12 GB 的*.journal文件，远远超出了预期。为了弄清楚它们是否值得保留，我跑了

journalctl --file $f

每个早于今天的文件；这总是导致Failed to open files或--- No entries ---。

我得出这样的文件是垃圾并且可以丢弃的结论是否正确？

If they are, why do they exist? What is a supported way to clean them up? Is it worthwhile to regularly check systems for their existence?

答案1

First of all Journal is a logging system and is part of systemd. Their existence is crucial when you need to know what happened.

As mentioned here, journalctl --file isn't that usable.

As the journal files are rotated periodically, this form is not really usable for viewing complete journals.

Now, whether you consider the files useless, that's for you to decide. Normally, too old logs are not worth keeping and you could delete them.

To do that, is best to use journalctl itself and its utility vacuum. For instance you can use

sudo journalctl --vacuum-time=3weeks

to delete all journal files that are more than 3 weeks old.

For more info check the man page with man journalctl.

--vacuum-size=, --vacuum-time=, --vacuum-files=

Removes the oldest archived journal files until the disk space they use falls below the specified size (specified with the usual "K", "M", "G" and "T" suffixes), or all archived journal files contain no data older than the specified timespan (specified with the usual "s", "m", "h", "days", "months", "weeks" and "years" suffixes), or no more than the specified number of separate journal files remain. Note that running --vacuum-size= has only an indirect effect on the output shown by --disk-usage, as the latter includes active journal files, while the vacuuming operation only operates on archived journal files. Similarly, --vacuum-files= might not actually reduce the number of journal files to below the specified number, as it will not remove active journal files.

Also, I don't believe its worthwhile to periodically check this. Best thing you can do is set an upper limit by uncommenting and changing the following in /etc/systemd/journald.conf.

For example:

SystemMaxUse=4G

Then restart the service. sudo systemctl restart systemd-journald.

Use man journald.conf for more information.

Edit:

As explained by @reinierpost

This question is not about regular old logs, it is about old logfiles that do not appear to contain any logs at all (but they still occupy 8 MB each).

Try running journalctl --verify. If files don't pass then the journal is corrupted and you should restart the service.

sudo systemctl restart systemd-journald

That should fix the problem for logs going forward.

As for why this happened in the first place, I don't know and its not easy to figure out. And yes, corrupted files are probably junk. You could try this for a clean slate.

答案2

I ran into something similar. On one of my Ubuntu 22.04 machines I had 81G of files in /var/log/journal going back 3 years. Actual log data shown by journalctl --utc --no-pager | head goes back about 6 days. My journald.conf file used all default (sane) values. I started checking other VMs and found similar issues.

I tried:

  • Set SystemMaxUse=10G and restart systemd-journald
  • Set RuntimeMaxUse=10G and restart systemd-journald
  • Set SystemMaxFileSize=1G and SystemMaxFiles=30 and restart systemd-journald
  • Set MaxFileSec=1month and restart systemd-journald

这些设置都没有从 中删除任何旧日志文件/var/log/journal。我也尝试过：

  • journalctl --flush --rotate
  • journalctl --rotate --vacuum-time=10days

所有旧文件都还在那里。

journalctl --disk-usage声称journald仅使用496M。

journalctl --verify将每项检查显示为“通过”，但只检查了/var/log/journal.我假设所有其他目录都被journald 孤立，但它们一直到当前日期，所以这是一个持续存在的问题。

我最终通过设置MaxFileSec=1month（这应该是默认设置）并添加每日 cron 作业来解决该问题，以find /var/log/journal -mtime +45 -delete删除日志应该删除但没有删除的任何垃圾。

相关内容