非常大的日志文件，我该怎么办？
（ 这个问题涉及类似的问题，但它讨论了一个旋转的日志文件。）
今天我收到了关于非常低/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) /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
现在，这些文件的大小为零。 重启前后系统运行正常。
我将在接下来的几天内观看这些文件（以及其他文件）并报告
他们表现得不合时宜。
最后一点，在/etc/logrotate.d/显示的文件检查（ grep帮助）时，两个有问题的文件（ kern.log和syslog ）都被设置为旋转。
更新2
日志文件实际上是旋转的。 看起来像是在一天内获得了大尺寸。
只需删除这些文件，然后重新启动？
没有。但是请不要使用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％。 也就是说，如果磁盘上还有空间可以做到这一点。
可能值得尝试建立填充日志的内容 – 或者通过使用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
我希望这个简单的解决方案对周围的其他人有用。