非常大的日志文件,我该怎么办?

Modified on: Wed, 20 Jun 2018 15:47:23 +0800

这个问题处理类似的问题,但它讨论了一个轮换的日志文件。)

今天我收到了关于/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

为什么一个进程想要超出限制的写入实际上超出了我的理解范围。如果这样的话,也许我想在这个论坛上提出一个不同的问题
即使在系统更新后仍会继续。)

然后,从此答案(您可能需要检查this for deep understanding),I
执行,

sudo su -
> kern.log
> syslog

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

我将在接下来的几天内观看这些文件(以及其他文件)并报告回来
他们表现得不合时宜。

最后一点,两个有问题的文件(kern.logsyslog)都被设置为旋转,作为文件的检查(grep帮助)里面
/etc/logrotate.d/显示。

更新2

日志文件实际上已旋转。看起来像是在一天内获得了大尺寸。

作者:Community,Masroor

最佳答案

  

只需删除这些文件,然后重新启动?

没有。清空它们但不使用rm,因为当您输入touch命令重新创建它时,它可能会崩溃。

最短的方法:

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

如果不是root,则需要sudo。取自AU上的另一个答案

在你这样做之前。做一个tail {logfile}并检查它们是否有这么大的原因。除非这个系统有几年的历史,否则没有理由这样做,解决这个问题比让这个问题更好。

kern.log和syslog通常都不应该那么大。但就像我说的那样:如果这个系统启动并运行多年,那可能是正常的,只需要清除文件。

并防止它在未来变得那么大:设置logrotate。它非常简单,当它变得比你设置的大小更大时会压缩日志文件。


另外一件事:如果您不想删除内容,可以通过tarring或gzipping压缩文件。这将使你最终得到的文件可能是他们现在的10%。也就是说,如果磁盘上还有空间可以做到这一点。


相关问答

添加新评论