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

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

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

日志文件实际上已轮换。看起来一天就可以达到大尺寸。

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

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

最短方法：

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

如果不是root用户，则需要sudo。取自澳大利亚的另一个答案。

在执行此操作之前。做一个，tail {logfile}并检查是否有它们太大的原因。除非该系统已经使用了几年，否则没有理由这样做，并且解决问题总比让它继续进行更好。

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

并防止它将来变得那么大：setup logrotate。它非常简单，当日志文件变得比您设置的大小大时将对其进行压缩。

1件事：如果您不想删除内容，则可以通过压缩文件或gzip压缩文件。那将使您最终获得的文件可能是现在文件的10％。也就是说，如果磁盘上仍有空间可以执行此操作。

可能值得尝试建立填充日志的内容-通过使用lessor 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

（请注意：鉴于文件如此之大，这可能需要一些时间），这将尝试剥离时间戳，然后计算最频繁出现的消息。

我清理系统日志文件的方法是这样的。步骤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
   

我们使用此日志（仅在几台服务器上）通过cron脚本进行logrotate和每周执行，所有带有* .1（或下一个旋转）的文件均由gzip压缩。

我今天安装了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

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