☰

/var/log/messages 无限增长，因为 rsyslog 不会让它被删除

tag-icon • tag-icon rsyslog deleted-files
/var/log/messages 无限增长，因为 rsyslog 不会让它被删除

我遇到了 /var 空间不足的问题，尽管它似乎只在 5 GB 分区上分配了 2 GB 文件。我确定问题是 /var/log/messages 已被删除，但仍由 rsyslog 打开并且为 2.88 gigs。

我现在可以通过重新启动 rsyslog 来解决该问题，从而释放要正确删除的 2.8 gig 文件。不过，我想知道它是怎么变成这样的状态的。 rsyslog 不应该自动轮换文件以防止日志无限增长吗？我可以做些什么来防止这种情况再次发生吗？

答案1

在许多发行版上，这种工作方式应该是通过 logrotate，它每天从 cron 或 systemd 计时器调用。 Logrotate 查找其配置，例如，在/etc/logrotate.d.举个例子，在 Debian 上你会发现/etc/logrotate.d/rsyslog，它会轮换/var/log/messages（以及许多其他日志文件），以下是摘录：

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

轮换文件后，它会告诉 rsyslog 通过运行 来关闭旧日志文件（通过重新启动 rsyslog 执行的操作）/usr/lib/rsyslog/rsyslog-rotate，这会SIGHUP向 rsyslogd 发送 a 。守护进程将在不重新启动的情况下关闭文件SIGHUP；看到rsyslogd(8) 的“信号”部分。

答案2

使用logrotate

手册页中的引用

logrotate 从命令行指定的一系列配置文件中读取有关它应该处理的日志文件的所有内容。每个配置文件都可以设置全局选项（本地定义覆盖全局选项，后面的定义覆盖早期的定义）并指定要轮换的日志文件。一个简单的配置文件如下所示：

# sample logrotate configuration file
compress

/var/log/messages {
    rotate 5
    weekly
    postrotate
        /usr/bin/killall -HUP syslogd
    endscript
}

配置文件的下一部分定义了如何处理日志文件 /var/log/messages。该日志在被删除之前将每周轮换五次。日志文件轮换后（但旧版本日志压缩之前），将执行命令 /sbin/killall -HUP syslogd。

相关内容