logo标签列表

如何从一个庞大的39.5GB /var/log/文件夹中释放空间？

disk-usagelogging
我刚收到一条来自默认磁盘分析软件（Baobab）的消息，说我的硬盘只剩下1GB了。经过一番搜索，我发现这是因为/var/log/文件夹造成的。 /var/log/文件夹中的一些文件/大小如下：
  • kern.log = 12.6 GB
  • ufw.log = 12.5 GB
  • kern.log.1 = 6.1 GB
  • ufw.log.1 = 6.0 GB
等等等等。 /var/log非常庞大。
我可以删除这些文件或整个/var/log文件夹吗？还是在Ubuntu中绝对不能这样做？
7个回答
你不应该删除整个文件夹，但是你可以删除“Old-Packed”日志文件而不会对系统造成任何损害。
对于普通家庭用户来说，安全的做法是删除那些被压缩并且扩展名为.gz的日志文件（如图所示）。
这些被压缩的日志文件是旧的日志文件，通过gzip压缩以减少存储空间，作为普通用户，你不需要它们。

Select .gz extention

19找到 /var/log 目录下所有后缀为 .gz 的文件并删除。 - diyism
@diyism 我试了你的代码，但帮助不大。我的日志目录仍然占用了6GB的空间 @_@ - GusDeCooL
4找到 /var/log -type f -name "*.gz" -delete。我删除了压缩文件，但只释放了约 1 GB 的空间。50 GB 对于 / 目录和我的磁盘其余部分的 /home 不够吗？ - Muhammad Gelbana
我妈妈的电脑上有一个大小为21 GB的kern.log文件。一个大的kern.log文件表示Linux内核本身或者它正在处理的某些问题存在问题。在这两种情况下，建议进入Linux shell终端并运行cat /var/log/kern.log或nano /var/log/kern.log（在图形界面中，可以运行类似gedit /var/log/kern.log或mousepad /var/log/kern.log的命令）来检查可能的问题。一旦找出问题所在，您可以运行sudo rm /var/log/kern.log ; sudo telinit 6来删除这个（大）文件并重新启动操作系统。 - Yuri Sucupira
3在我的情况下，这将只删除41个文件中的15.7 MB。真正的问题在于messages（7.7 GB）、user.log（7.7 GB）、syslog（4.1 GB）和syslog.1（3.5 GB）。这四个文件总共占用了23 GB的空间。有没有办法删除它们，或者至少减小它们的大小？ - Rodrigo
@YuriSucupira 我觉得将整个日志文件 (cat /var/log/kern.log) 输出并不是一个明智的做法。 - Ismail
@Ismail 我知道在大文件上运行 cat 会花费很多时间，但如果这个文件是你关于影响你的操作系统的问题唯一的信息来源，那可能只有这种方式了。不过，如果有人更倾向于删除日志文件中除了最后 N 行之外的内容，可以运行类似以下命令：tail -N /var/log/kern.log |sudo tee /var/log/kernel.log。例如，如果想要保留最后的1000行，只需运行 tail -1000 /var/log/kern.log |sudo tee /var/log/kernel.log，这样内核日志将被缩减为仅包含最后1000行的文件。 - Yuri Sucupira
@Ismail 另一个tail的好用途是在用户还没弄清楚系统出了什么问题之前，保留kern.log文件。这样的用户可以使用类似于tail -N /var/log/kern.log |grep -i word的命令，在kernel.log的最后N行中使用grep来查找用户怀疑可能在这些行中找到的词，以解决影响系统的问题。最后但同样重要的是，tail -N /var/log/kern.log |sudo tee /var/log/analysis.log将创建analysis.log，其中只包含kernel.log的最后N行。 - Yuri Sucupira
尽管有这些庞大的日志文件（可以直接删除，或者如上所述使用tail进行“缩小”），一个很好的用于清理系统的“日常使用”应用程序是Bleachbit（请访问https://www.bleachbit.org），您可以使用`sudo apt-get install bleachbit -y`命令进行安装。 - Yuri Sucupira
@YuriSucupira cat并不是唯一的简化工具，有多种方法可以实现这个功能。这只是一个简单的建议，你不应该推荐人们使用cat，而是使用less。对于大文件来说，使用tail比使用cat更明智，因为cat会输出所有内容，而只有最后x行（取决于终端设置）可见。 - Ismail
@Ismail 我在某些情况下使用less（和more），但是因为原帖/问题涉及到一个非常大的日志文件，我绝对不会使用less：在这种情况下，使用less会导致在如此庞大的日志文件中查找相关内容需要很长时间。无论如何，你关于tail的观点是正确的，它比使用cat更智能。^..^ - Yuri Sucupira
正如@Rodrigo在上面提到的，这只是删除了最小的文件。而下面richvdh的回答实际上解决了这个问题。https://askubuntu.com/a/100014/315699 - Homero Esmeraldo
我不会删除整个/var/log文件夹 - 那样会导致问题。
你可以像@jrg建议的那样销毁日志 - 但是除非写入日志文件的东西（主要是syslogd）被重新启动，否则这实际上不会为您恢复任何磁盘空间，因为文件将继续以已删除状态存在，直到文件句柄关闭。
更好的方法是找出为什么日志没有被轮转（然后删除）。logrotate应该为您完成此操作，我怀疑它没有按照每晚应该运行的方式运行。
我首先要做的事情是：
sudo /etc/cron.daily/logrotate

这个操作应该会轮转日志文件（所以kern.log变成kern.log.1）；然后你可以删除kern.log.1等来释放磁盘空间。
如果到目前为止一切都正常，那么下一个问题是为什么这不会自动发生。如果你晚上关机，请确保你安装了anacron。
我执行了 sudo /etc/cron.daily/logrotate 命令，但文件没有发生变化。 - Homero Esmeraldo
5我使用了logrotate -vf /etc/logrotate.conf命令手动轮转日志。来源：https://www.linuxnix.com/how-to-rotate-logs-manually-in-linux/ - Homero Esmeraldo
免责声明：我对此并不是专家，使用需自负风险！
在发现我的 /var/log/journal 文件夹占用了数GB后，我按照以下步骤进行操作：

https://ma.ttias.be/clear-systemd-journal/

journalctl --vacuum-time=10d

清除了90%以上的内容
在Ubuntu 18、20和22上运行得非常顺畅。 - josircg
你应该查看日志，看看它们记录了什么。我猜测是ufw/iptables（你正在记录所有网络流量）。 ufw - 当你记录所有数据包时，日志会变得很大。如果你不打算审查这些日志，请关闭记录功能。如果你想监控你的网络，请使用snort。Snort将筛选你接收到的成千上万个数据包，并向你报警可能存在问题的流量。
我猜测ufw是罪魁祸首，你在kern.log中记录的数据包太多了。
有时候可能出现内核或硬件问题导致日志满了。在这种情况下，最好修复问题或提交一个bug报告，你需要审查日志来完成这项工作。
如果你无法解决问题，可以配置syslog以避免填满日志。
参考 http://manpages.ubuntu.com/manpages/precise/man5/syslog.conf.5.html 获取更多信息。
如果你提供更多关于问题的细节，我们可以帮助更好地进行调试。
2这是一个非常好的观点。值得找出是什么堵塞了日志，而不仅仅是删除它们。+1。 - richvdh
删除/var/log可能不是一个好主意，但删除单个日志文件应该没问题。
在我的笔记本电脑上，使用较小的SSD硬盘，我将/var/log（以及/tmp和/var/tmp）设置为tmpfs挂载点，通过在/etc/fstab中添加以下行来实现：
temp        /tmp        tmpfs   rw,mode=1777    0   0
vartmp      /var/tmp    tmpfs   rw,mode=1777    0   0
varlog      /var/log    tmpfs   rw,mode=1777    0   0

这意味着那些目录下的所有内容在重启后都会消失。据我所知，这个设置运行良好。当然，我失去了查看旧日志以诊断可能发生的问题的能力，但我认为这是为了减少磁盘使用而进行的公平权衡。
我遇到的唯一问题是，某些程序（尤其是APT）希望将其日志写入/var/log的子目录中，并且不够聪明，在不存在这些目录时创建它们。将mkdir /var/log/apt这行添加到/etc/rc.local解决了我的特定问题；根据您安装了哪些软件，您可能还需要创建其他一些目录。
（另一种可能性是创建一个简单的tar归档文件，仅包含目录，并在启动时将其解压缩到/var/log，以一次性创建所有所需的目录并设置其权限。）
1ufw是问题的原因，显然我将日志设置为FULL，所以它记录了所有的内容。谢谢你的帮助 :) - blade19899
我遇到一个问题，那就是巨大的日志文件（每个约100G），里面有一些来自gnome的无用信息，比如“无法找到视频缓冲区”之类的。尝试了以下操作：
sudo rm -rf /var/log/user.log sudo rm -rf /var/log/syslog sudo rm -rf /var/log/messages
但并没有解决问题，然而，在删除这些文件后，立即执行以下命令： systemctl restart syslog.service 可以释放出这些文件占用的空间。
现在是rsyslog吗？ https://www.redhat.com/sysadmin/rsyslog-systemd-journald-linux-logs - Pysis
@Pysis看起来是这样的。在Debian上，syslog仍然可以工作，但返回的是rsyslog。 - n.podbielski
我有一个几个GBytes的/var/log文件夹，我使用/etc/systemd/journald.conf和logrotate将其缩小到不到250MBytes：
journald的配置：（参见man journald.conf）
SystemMaxUse=250M
SystemMaxFileSize=50M

/etc/logrotate.conf的配置：

compress

/var/log/journal {
    daily
    dateext
    delaycompress
    copytruncate
    notifempty
    missingok
    rotate 3
    size 500k
    sharedscripts
}

请查看/etc/logrotate.d/*中的文件。
这不是一个解决方案。即使您对logrotate配置进行了更改，日志文件在每次运行logrotate之间可能会增长到多个GB - 通常一天运行一次。查看最大的活动日志文件（使用tail -f filename.log命令）以确定真正的问题，然后解决该问题。 - Soren A
@SorenA $ du -sh /var/log 现在的结果是233M，而之前几乎是5GB。也许对你来说还存在问题，但这显然是关于“大量/var/log”问题的一个解决方案。 - Stephane Rolland
1只去除症状而不解决根本原因是不专业的做法。这样做会导致日志文件中出现各种“噪音”，或者它们过于短暂，以至于在你的服务器真正遇到问题的时候，日志文件中不包含所需的历史数据，或者你在所有垃圾中找不到它们。 - Soren A
@SorenA 感谢你的备注。我仔细查看了日志，并注意到一个经常出现的错误信息，这个错误似乎经常重复出现，可能是导致几个月来产生大量数据的原因。虽然不是关键问题，但必须解决这个问题。 - Stephane Rolland
不要限制得太严，否则你将无法找到制造噪音的应用程序，例如：sudo sed s/#SystemMaxUse=$/SystemMaxUse=500M/g /etc/systemd/journald.conf -i。 - rubo77