问题描述
( This question 处理类似的问题，但它讨论的是轮换的日志文件。)
今天我收到一条关于 /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
首先，该系统只有几个月的历史。几个月前，我不得不在硬盘崩溃后从头开始安装系统。
现在，按照 this answer 中的建议，我首先使用 tail 检查了有问题的日志文件，这并不奇怪。然后，为了更深入的检查，我从 same answer 执行了这个脚本。
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 answer(你可能想检查 this 以获得更深入的理解)，我执行，
sudo su -
> kern.log
> syslog
现在，这些文件的大小为零。系统在重新启动前后运行良好。
在接下来的几天内，我将观看这些文件(以及其他文件)，如果它们的行为 out-of-line，我会向您报告。
最后要注意的是，两个违规文件( kern.log 和 syslog )都设置为旋转，如检查 /etc/logrotate.d/ 中的文件( grep 帮助)所示。
更新 2
日志文件实际上是轮换的。看起来大尺寸是在一天内达到的。
最佳方法
Simply delete these files and then reboot?
不。清空它们，但不要使用 rm，因为当您键入 touch 命令以重新创建它时，它可能最终导致崩溃。
最短方法：
cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log
> kern.log
> syslog
exit
如果不是 root，它将需要 sudo 。取自 AU 上的另一个 answer。
在你这样做之前。做一个 tail {logfile} 并检查它们是否有如此大的原因。除非这个系统已经使用了好几年，否则应该没有理由这样做，解决问题总比让它继续下去要好。
kern.log 和 syslog 通常都不应该那么大。但就像我说的：如果这个系统已经启动并运行多年，它可能是正常的，只需要清除文件即可。
并防止它在未来变得那么大：设置 logrotate 。它非常简单，当日志文件变得大于您设置的大小时会压缩它。
另一件事：如果您不想删除内容，您可以通过 tarring 或 gzip 压缩文件。这将使您最终得到的文件可能只有现在的 10%。也就是说，如果磁盘上还有空间可以做到这一点。
次佳方法
尝试确定正在填充日志的内容可能是值得的 – 只需使用 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
(注意：考虑到如此大的文件，这可能需要一些时间)它会尝试去除时间戳，然后计算最常出现的消息。
第三种方法
我清理系统日志文件的方法是这样的。步骤 1 和 2 是可选的，但有时您需要检查较旧的日志，而备份有时很有用。 😉
-
可选：复制日志文件
cp -av --backup=numbered file.log file.log.old -
可选：在日志副本上使用 Gzip
gzip file.log.old -
使用 /dev/null 清理文件
cat /dev/null > file.log
我们使用此日志(仅在几台服务器上)logrotate 并每周通过 cron 脚本执行，所有带有 *.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
我希望这个简单的解决方案对其周围的其他人有用。