☰

如何限制我的系统日志的大小？

tag-icon • tag-icon syslog usbfs
如何限制我的系统日志的大小？

我妈妈的电脑运行的是 Ubuntu 12.04 LTS。它一直运行良好，但系统日志突然就满了。所谓填满，是指我刚刚删除了一个/var/log/syslog400GB 大小的文件。是的 - 几 GB。

虽然我确信其中有一些有用的信息，但我不确定 400GB 是否值得仔细查看。真正令人惊奇的是，这件事发生在 8 小时内 - 我df中午左右开始运行，从那时到现在，她的驱动器已占用 30%（从不到 70% 到 100%）。

这可能是什么原因造成的？我该如何解决？

编辑 看起来 USB 是罪魁祸首：

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

答案1

限制logrotate的大小

打开/etc/logrotate.d/rsyslog配置文件

sudo nano /etc/logrotate.d/rsyslog

该文件看起来像

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

size 100k 在括号中添加 eg 。之后它应该看起来像：

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

请注意，这限制了轮换文件的文件大小，而不是实际的 syslog 文件。保存文件。下次启动 logrotate chron 作业时，它将限制轮换日志的大小。

限制当前系统日志的大小

要限制的大小/var/log/syslog，您必须编辑/etc/rsyslog.d/50-default.conf，并设置固定的日志大小。

通过更改以下行来添加或修改此设置/etc/rsyslog.d/50-default.conf：

.*;auth,authpriv.none       -/var/log/syslog

以下是rsyslog 手册：

输出通道通过 $outchannel 指令定义。其语法如下：

$outchannel name,file-name,max-size,action-on-max-size

name 是输出通道的名称（不是文件），file-name 是要写入的文件名，max-size 是允许的最大大小，action-on-max-size 是达到最大大小时要发出的命令。此命令始终只有一个参数。二进制是 action-on-max-size 中第一个空格之前的部分，其参数是该空格后面的所有内容。请注意，在将日志消息写入文件之前会查询 max-size。因此，请确保将此限制设置为合理的低值，以便任何消息都可以容纳。对于当前版本，将其设置为比预期低 1k 是有帮助的。max-size 必须始终以字节为单位指定 - 在开发阶段没有特殊符号（如 1k、1m 等）。请记住，$outchannel 仅用“名称”定义通道。它不会激活它。为此，您必须使用选择器行（见下文）。该选择器行包括通道名称以及前面的 $ 符号。示例可能是：。:omfile:$mychannel 在其当前形式中，输出通道主要提供限制输出文件大小的功能。为此，请指定最大大小。当达到此大小时，rsyslogd 将执行 action-on-max-size 命令，然后重新打开文件并重试。该命令应该类似于日志轮换脚本或类似的东西。

如果没有 action-on-max-size 命令或该命令无法解决问题，则文件将被关闭，并且永远不会被 rsyslogd 重新打开（当然，除非通过 huping 操作）。当我们第一次遇到超过 2gb 的文件的严重问题时，就集成了此逻辑，这可能导致 rsyslogd 转储核心。在这种情况下，停止写入单个文件更为合适。同时，rsyslogd 已修复以支持超过 2gb 的文件，但显然仅限于支持它的文件系统和操作系统版本。因此，强制执行 2gb 文件大小限制仍然有意义。

这里的最大大小是 1MB，请将此行放在该*.*; ...行之前

$outchannel mysyslog,/var/log/syslog,1048576

并将*.*; ...行改为

*.*;auth,authpriv.none  :omfile:$mysyslog

使用以下命令重启 rsyslogd

sudo systemctl restart  rsyslog.service

或者

sudo service rsyslog restart

要查看 rsyslog 状态类型

systemctl status rsyslog.service

答案2

您应该找出导致大量消息的原因，就好像您解决了这个问题，然后就修复了大型日志文件。

然而，在此之前，您可以根据以下之一放入日志轮换基础。

  • 时间（例如每天轮换）
  • 尺寸（例如当文件达到 10mb 时旋转）

系统已默认设置此项：/etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

从中你可以看到它将轮换 /var/log/syslog 文件日常的并保持7 份旋转文件。

您可以将其更改为在大小限制（例如 1mb）上旋转或减少其存储的副本数量。

警告：这不会解决问题的根本原因，但是它会为您赢得一些时间，因为它会阻止文件系统被填满。

  • 来源：/etc/logrotate.d/rsyslog
  • 来源：man logrotate

答案3

两周以来，我的 Lexmark Pro915 一直存在同样的问题。我做了两件事，现在它工作正常了。我重新安装了驱动程序。（不要以为这是有帮助的。）我取出了我正在使用的 USB 延长线，这使得总长度几乎达到 15 英尺，而且可能不完全兼容。我怀疑 Linux 系统的 Lexmark 驱动程序可能检测到信号较差或时间不准，并且想要每天向您报告 100 亿次。尝试以某种方式改善您的连接。

Logrotate 和类似的解决方案对我没有帮助。Kern.log 和 syslog 每天总共记录超过 1TB！如果您可以将 Logrotate 设置为每 12 分钟运行一次，它可能会有所帮助。

相关内容