在 logrotate 后 Gunicorn 拿着旧原木答案

【问题标题】：Gunicorn holding onto old logs after logrotate在 logrotate 后 Gunicorn 拿着旧原木
【发布时间】：2014-07-31 12:17:18
【问题描述】：

我正在使用 logrotated 来旋转 gunicorn 访问日志。这是我的 logrotated 配置

/opt/api/log/access.log {
    daily
    rotate 10
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
        killall -s USR1 gunicorn
    endscript
}

日志被正确轮换、压缩，并创建了一个新的 access.log。但是，gunicorn 不会释放指向旧日志文件的“指针”，因此旋转实际上并没有释放磁盘空间。

我仍然可以使用 lsof 看到它的条目

如果我执行 initctl restart api ，gunicorn 将重新启动并最终释放磁盘空间。

如何以比重启服务更干净的方式释放磁盘空间？

【问题讨论】：

您找到解决方案了吗？可以分享一下配置文件吗？
gunicorn 错误修复已于 11 月发布 (github.com/benoitc/gunicorn/releases/tag/19.4)。如果您使用的是较新版本的 gunicorn，您应该不会遇到此问题，如果您仍然看到它，您应该使用 gunicorn 提交错误
你能分享配置文件吗，我在任何地方都找不到？
gunicorn documentation 现在推荐重启命令：kill -USR1 $(cat /var/run/gunicorn.pid)

标签： python gunicorn logrotate

【解决方案1】：

通常Linux 进程接受一个特殊的signal 来通知它们有关日志文件轮换的信息。在这种情况下，您将发送信号 SIGUSR1 以处理系统上的所有 gunicorn 进程。

问题是

你的运行系统中是否存在这样的进程
gunicorn 进程是否接受SIGUSR1 信号

根据 gunicorn 源代码，USR1 确实应该轮换日志

https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/base.py#L139

...所以我怀疑killall 可能没有将命令发送到正确的进程。

要找出这一点，请使用ps 检查您的进程列表。如果发现gunicorn 进程，修改workers/base.py 以打印日志条目以查看它们是否收到信号。尝试手动发送信号，如果它有效，那么它是 logrotate 配置，它不起作用。

【讨论】：

【解决方案2】：

回答我自己的问题，似乎我遇到了这个错误：https://github.com/benoitc/gunicorn/issues/627

有一个修复程序，但尚未发布。

【讨论】：