Upstart不会在logrotation上重新打开日志文件

我们使用新贵来管理我们在Ubuntu服务器上的服务。它们生成的日志已注销到/var/log/upstart/SERVICE_NAME.log

然后每天使用12.04 LTS随附的logrotation脚本轮换日志文件：

/var/log/upstart/*.log {
        daily
        missingok
        rotate 7
        compress
        notifempty
        nocreate
}

问题在于，尽管logrotate移动文件，但似乎没有信号指示upstart关闭并重新打开文件，从而使upstart进程写入删除PID。

init          1       root    8w      REG              202,1        64       2431 /var/log/upstart/dbus.log.1 (deleted)
init          1       root   13w      REG              202,1        95       2507 /var/log/upstart/acpid.log.1 (deleted)
init          1       root   14w      REG              202,1       127      17377 /var/log/upstart/whoopsie.log.1 (deleted)
init          1       root   36w      REG              202,1       122       6747 /var/log/upstart/SERVICE_NAME.log.1 (deleted)
init          1       root   37w      REG              202,1        30       6762

显然，我可以将输出从自己的服务重定向到其他日志文件，但是问题仍然存在于系统进程中。另外，我宁愿不必构建超出我所需的基础架构。

upstart init logrotate

— 安德鲁·纽迪格特（Andrew Newdigate）
source

我也刚遇到这个。很奇怪，我们以前没有注意到它，这让我认为这可能是最近发生的事情。

— pwaller 2014年

这事有进一步更新吗？在14.04上看到了完全相同的问题。由于存在该nocreate指令，因此不确定为什么有人会使用该指令，尤其是对于可能编写大量输出的服务

— rynop 2014年

也经历了这一点。

— Ztyx

我发现了这个错误

— Lety 2015年

Answers:

我相信您有3个选择。

您通过添加“ copytruncate”来修改现有配置

/var/log/upstart/*.log { copytruncate daily missingok rotate 7 compress notifempty nocreate }
如果由于没有其他日志文件而无法更改（或不允许）更改现有logrotate配置，并且现有配置适用于它们，则将“ SERVICE_NAME.log”文件移至/下的新文件夹var / log（如果需要），使用“ copytruncate”创建一个新配置，并将其添加到cron.daily。
a）如果不允许您更改主机操作系统logrotate配置或将其添加到主机操作系统的cron.daily，那么您的第三个选择是更改脚本或程序，以在写入文件之前检查文件是否存在。b）另一种方法是在第2点上一点，它是将日志文件移动到其他位置，并在脚本或程序中执行该程序的日志文件专用的logrotate命令。

上面的第3b点比较棘手，但是更优雅，这是我大部分时间使用的，因为这意味着该程序是自给自足的并且可以自我管理，不需要操作系统的工作来照看它。

要了解如何手动运行logrotate并将其添加到程序或脚本中，只需键入：

man logrotate

要么

logrotate --help

如果您在程序中使用Python，则可以查看该程序如何使用它来自我管理其日志文件。 http://bazaar.launchpad.net/~ferncasado/keep.awake/trunk/files/head:/v4/

— 悬空指针
source

事实证明，这是一个已知问题，在我键入此票证时，票证仍处于打开状态。

正确的做法可能是/etc/logrotate.d/upstart完全删除并单独旋转各个服务的文件。因为目录（/var/log/upstart/）仅包含各种服务的stdout / stderr，并且根本不打算将作为守护程序运行的服务输出到这两个通道。除了，也许在刚开始的时候。

在我管理的系统，三个服务由新贵运行：php5.6-fpm，php7.1-fpm，和acpid。这三个日志都没有处于活动状态，但是有时fpm由于其主日志文件（/var/log/php5.6-fpm.log）旋转而重新启动-并引起这种噪音，因为它在启动时会输出一些烦恼。

如果您仍然坚持旋转这些文件，则可以依靠以下事实：它们的名称与服务的名称匹配，并使用以下postrotate脚本：

    postrotate
            service=${1##*/}
            service=${service%.log*}
            service $service restart > /dev/null
    endscript

为了使上述方法起作用，请确保不要~~sharedscripts~~在其中使用动词-我的脚本依赖于事实，文件的实际路径将作为第一个参数（$1）传递给它。

（重定向到/dev/null是有用的，因为service-command太吵了-而且您不希望cron通过电子邮件将此类噪音发送给您。请注意，我不是在这里重定向stderr，仅是stdout-如果有问题，您可以仍然会收到您的电子邮件。）

— 米哈伊尔（Mikhail T.）
source