☰

日志文件非常大，我该怎么办？

tag-icon • tag-icon filesystem system log
日志文件非常大，我该怎么办？

（这个问题处理类似的问题，但它讨论的是旋转的日志文件。

/var今天我收到一条关于空间非常小的系统消息。

和往常一样，我执行了该行中的命令，但sudo apt-get clean情况仅略有改善。然后我删除了轮换的日志文件，但同样没有带来任何改善。

经过检查，我发现 中的一些日志文件/var/log已经变得非常大。具体来说ls -lSh /var/log，

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

我们可以看到，前两个文件有问题。我有点惊讶为什么这么大的文件没有被轮换。

那么，我该怎么办？直接删除这些文件然后重启？还是采取一些更谨慎的措施？

我正在使用 Ubuntu 14.04。

更新 1

首先，这个系统才几个月前。几个月前硬盘崩溃后，我不得不从头安装这个系统。

现在，正如这个答案，我首先使用检查了有问题的日志文件tail，这并不奇怪。然后，为了进行更深入的检查，我从同样的答案。

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

这个过程花了几个小时。输出结果如下：

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

（/dev/sda3是我的主目录。我们可以发现，

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

为什么一个进程会想要超出限制写入，这实际上超出了我的理解范围。如果系统更新后这种情况仍然存在，也许我会想在这个论坛上问一个不同的问题。）

然后，从这个答案（你可能想检查一下这为了更深入地理解），我执行了，

sudo su -
> kern.log
> syslog

现在，这些文件的大小为零。系统在重启之前和之后运行正常。

我将在接下来的几天内观察这些文件（以及其他文件），如果
它们的行为异常，我将报告。

最后要注意的是，有问题的文件（kern.log和syslog）都设置为轮换，正如检查grep里面的文件（帮助） /etc/logrotate.d/所显示的那样。

更新2

日志文件实际上是轮换的。看起来这些大文件是在一天之内就生成的。

答案1

只需删除这些文件然后重新启动吗？

不。清空它们但不要使用，因为在您键入命令重新创建它rm时可能会导致某些东西崩溃。touch

最短方法：

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

如果不是 root 用户，则需要sudo。取自另一个回答在 AU 上。

在你这样做之前。先tail {logfile}检查一下是否有理由让它们这么大。除非这个系统已经好几年了，否则应该没有理由这样做，解决问题总比放任不管要好。

kern.log 和 syslog 通常不会那么大。但就像我说的：如果这个系统已经运行了很多年，这可能是正常的，只需要清除这些文件。

为了防止将来日志文件变得那么大：setup logrotate。这个方法很简单，当日志文件变得比你设置的大小大时，它会压缩日志文件。

还有一件事：如果您不想删除内容，您可以通过 tarring 或 gzip 压缩文件。这样最终文件大小可能只有现在的 10%。前提是磁盘上还有空间可以这样做。

答案2

也许值得尝试确定日志中的内容 - 只需使用less或tail命令进行目视检查即可

tail -n 100 /var/log/syslog

或者如果问题线路埋得太深，不容易看到正在发生的事情，比如

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

（注意：由于文件很大，这可能需要一些时间）它将尝试去除时间戳，然后计算最常出现的消息。

答案3

我清理系统日志文件的方法是这样的。步骤 1 和 2 是可选的，但有时您需要检查旧日志，备份有时很有用。;-)

  1. 可选：复制日志文件

    cp -av --backup=numbered file.log file.log.old

  2. 可选：对日志副本使用 Gzip

    gzip file.log.old

  3. 使用 /dev/null 作为清理文件

    cat /dev/null > file.log

并且我们对这些日志（仅在几台服务器上）使用 logrotate 并每周通过 cron 脚本执行，其中所有带有 *.1（或下一个旋转）的文件都通过 gzip 压缩。

答案4

我今天安装了 Ubuntu 16.04，也发现了同样的问题。不过，我用 busybox-syslogd 修复了这个问题。是的！我刚刚安装了该软件包，问题就解决了。:)

$ sudo apt-get install busybox-syslogd

安装该软件包后，重置syslog并kern.log：

sudo tee /var/log/syslog /var/log/kern.log </dev/null

我希望这个简单的解决方案对周围的其他人有用。

相关内容