☰

为什么RHEL中的logrotate使用kill -HUP？是否在所有情况下都有必要？

tag-icon • tag-icon signals syslog rsyslog logrotate sighup
为什么RHEL中的logrotate使用kill -HUP？是否在所有情况下都有必要？

我看到系统日志记录使用了kill -HUP。

/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

我理解使用 -HUP 是因为像 syslog 这样的守护进程，当它们捕获 SIGHUP 时，将尝试重新启动自身，因此所有打开的文件将被刷新。

我不明白为什么他们需要刷新。

如果 syslog 仅将新日志附加到日志文件，则打开的文件将处于写入模式。如果是这种情况，当日志切换发生时，并且在文件系统中的旧日志文件条目被删除时，当需要附加新日志行时，它不会自动创建一个新文件（毕竟 syslog服务以 root 身份运行）？

我认为区别更多在于对w和u模式的理解。我无法对此快速得出结论。

另外，为什么只使用kill -HUP，为什么不重新启动服务。会有什么不同吗？

答案1

通常，服务在运行时保持日志文件打开。这意味着他们不关心日志文件是否被重命名/移动或删除，他们将继续写入已处理的打开文件。

当 logrotate 移动文件时，服务会继续写入同一文件。

示例：crond 将写入 /var/log/cron.log。然后logrotate会将文件重命名为/var/log/cron.log.1，因此crond将继续写入打开的文件/var/log/cron.log.1。

向 crond 发送 HUP 信号将迫使他关闭现有文件句柄并打开原始路径 /var/log/cron.log 的新文件句柄，这将创建一个新文件。

使用 HUP 信号而不是其他信号由程序自行决定。某些服务（例如 php-fpm）将侦听 USR1 信号以重新打开其文件句柄，而不会终止自身。

答案2

当您移动文件时，打开该文件的程序仍然会在新位置打开相同的文件，并且会继续附加到旧的日志文件。不一定kill -HUP会使其自行重新启动（对于 syslog 来说确实如此，但对于管理自己日志的 cron 守护进程来说，它只是控制日志文件本身），但可能只是导致它关闭文件并打开文件按名字，这是该脚本的重要部分。对 syslogd 进行硬重启还意味着 syslogd 服务在重新启动时不可用，而使用 syslogd 知道如何处理的信号允许它执行“重新启动”透明所需的任何操作。

相关内容