☰

我的 /var/log/ 在几分钟内就神秘地填满了 GB！在我重新安装 Debian 7 之前有什么解决办法吗？

tag-icon • tag-icon shell debian process disk-usage troubleshooting
我的 /var/log/ 在几分钟内就神秘地填满了 GB！在我重新安装 Debian 7 之前有什么解决办法吗？

早上好，*nix 爱好者们！

我已经使用 Debian 7 一段时间了，在最近的升级之后，我注意到我的根分区上的空间不断不足。我的意思是磁盘上还剩下“0”字节！所以，经过一个很多在搜索过程中，我能够将 /var/log 文件夹归零。我曾经ls -s -S在这个文件夹中按大小排列文件，发现有三个文件大小为 GB（例如 13-15 GB）：

  • 系统日志
  • 消息
  • 内核日志

是的，logrotate工作正常。它正在旋转日志。例如，我在 /var/log 中看到 kern.log.1 等。问题是日志填满的速度非常快，以至于 logrotate 无能为力。

显然，操作系统中的某些日志记录进程正在写入大量数据，这可能是由于持续的错误或其他原因（??）。我不知道。我只知道我的笔记本电脑过热只是因为正在进行太多处理每时每刻由于这个不断的写入过程。所以，我正在失去 CPU 能力和磁盘空间。

我的问题是：如何确定哪个进程/守护进程正在创建此问题？如何找到问题的根本原因以便纠正它？读取这些巨大的日志文件不是一个选择。请。如果我尝试在已经很繁忙的笔记本电脑上使用 Leafpad 或记事本等文本编辑器提取 15 GB 的日志文件，则需要很长时间才能打开。那是不切实际的。

我意识到这个问题很广泛，因为可能有任何进程/守护进程导致这种情况，但我想知道是否有人以前经历过这种情况，以及是否有任何常见的嫌疑人我可以看看。

更新：

按照Eric的建议，我按照修改时间排列了/var/log中的文件，“syslog”是最后一个。所以，我tail编辑了它。结果：

Apr 10 00:53:37 MyMachine kernel: [11608.690733]  [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]
Apr 10 00:53:37 MyMachine kernel: [11608.690742]  [<ffffffff81084f57>] ? process_one_work+0x147/0x3b0
Apr 10 00:53:37 MyMachine kernel: [11608.690750]  [<ffffffff81085764>] ? worker_thread+0x114/0x480
Apr 10 00:53:37 MyMachine kernel: [11608.690756]  [<ffffffff81556065>] ? __schedule+0x2e5/0x790
Apr 10 00:53:37 MyMachine kernel: [11608.690765]  [<ffffffff81085650>] ? create_worker+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690772]  [<ffffffff8108ae91>] ? kthread+0xc1/0xe0
Apr 10 00:53:37 MyMachine kernel: [11608.690780]  [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690788]  [<ffffffff8155a23c>] ? ret_from_fork+0x7c/0xb0
Apr 10 00:53:37 MyMachine kernel: [11608.690795]  [<ffffffff8108add0>] ? kthread_create_on_node+0x1c0/0x1c0
Apr 10 00:53:37 MyMachine kernel: [11608.690800] ---[ end trace 12dc8d8439345c1d ]

不幸的是，它没有给我太多提示。

答案1

syslog您发布的片段中实际上有一个强烈的暗示。行尾

Apr 10 00:53:37 MyMachine kernel: [11608.690733]  [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]

显示堆栈跟踪是由于名为 的设备驱动程序中出现意外错误造成的ath9k_htc。希望内核没有惊慌，但不断重复的错误正在填满您的文件系统。

然后我会ath9k_htc使用此命令将 wifi 驱动程序列入黑名单，然后重新启动：

echo "blacklist ath9k_htc" | sudo tee -a /etc/modprobe.d/blacklist.conf

ath9k_htc请注意，如果驱动程序在出现错误的情况下仍被使用且正常工作，那么这样做可能会阻止您的 WiFi 工作。

您可以通过运行来检查驱动程序期望的 wifi 设备是否ath9k_htc存在于您的计算机中lsusb，并查看设备是否与此处提供的列表之一匹配：https://wiki.debian.org/ath9k_htc

答案2

您无需在编辑器中打开日志文件即可查看日志文件中的内容。只要看最后几行：

tail -n 999 /var/log/syslog | less

进程的日志文件始终包含进程 ID：

Apr 10 00:00:01 harfang /USR/SBIN/CRON[345]: (root) CMD ( /usr/local/bin/midnight-stuff )
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm bored

这告诉您进程 1234（wibbled守护进程的一个实例）正在生成大量日志消息。您可能想杀死它并检查它的配置。

如果kern.log增长很多，则您的日志不是来自进程，而是来自内核。内核日志中的洪泛现象很少见，而且更难确定。这可能是由于一个进程在紧密循环中重新生成并立即崩溃（可能是由于系统内存不足）。这也可能是由于越野车司机造成的。您需要查看消息以了解原因。

就您而言，您会看到来自驱动程序的回溯。驱动程序不断遇到非致命错误。尝试卸载它：

rmmod ath9k

（为什么ath9k？因为这是提供该功能的驱动程序ath9k_reg_rmw，但实际上是因为模块名称将在您问题中包含的位的几行后面提到。）如果驱动程序不在模块中或无法卸载，寻找另一种方法来禁用它或停止触发它的错误；如何做到这一点取决于它是什么驱动程序以及它出了什么问题。

答案3

我已经按照说明解决了问题这里。

方法一

添加pci=noaer到您的内核命令行：

  1. 编辑/etc/default/grub和 添加pci=noaer到以 开头的行GRUB_CMDLINE_LINUX_DEFAULT。它看起来像这样： 
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer"
  2. 跑步 
    sudo update-grub
  3. 重启

它减少了日志文件的大小，停止了巨大的增长。

方法2

如果它也没有帮助，您可以编辑相同的内容

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer pci=nomsi"

参考

但是，我不知道这是否解决了错误消息的根本原因......

相关内容