删除的日志文件神秘地重新出现

发布于 2024-12-14 02:47:05 字数 781 浏览 5 评论 0原文

我使用 nginx 运行乘客,几个月前我删除了一个耗尽磁盘空间的 nginx 日志文件,特别是 /var/log/nginx/error.log.1,大小约为 5GB,然后重新配置 logrotate 以保留日志文件大小减小。一切都很好,直到几天后,删除的文件被 Passenger 进程以某种方式回收(如 lsof +L1 所示)。看起来已删除的文件大小增加了,因此显然它正在被写入。我也不知道为什么它想要写入 error.log.1 ,因为那是一个旋转的日志文件(尽管已经很长时间了,我不确定我是否将 error.log 重命名为 error.log.1 )删除/移动东西,这可能与问题有关)通过 touch tmp/restart.txt 重新启动乘客并没有更改 lsof +L1 也没有回收磁盘空间,但重新启动 nginx 却做到了。
现在真正奇怪的是,从那时起系统已经重新启动,问题仍然出现。几天或几周过去了,然后突然可用磁盘空间缩小,我检查 lsof +L1 并再次看到已删除的文件。这里到底发生了什么?知道这是如何发生的会很有趣,并且了解我如何能够阻止它再次发生会很有帮助。谢谢。

日志旋转配置如下所示: /var/log/nginx/*.log { 日常的 米索克 旋转52 压缩 延迟压缩 通知空 创建 640 root adm 共享脚本 后旋转 [! -f /var/run/nginx.pid ] || Kill -USR1 cat /var/run/nginx.pid 尾稿 }

I run passenger with nginx and some months ago I deleted an nginx log file that was using up my disk space, specifically /var/log/nginx/error.log.1, about 5GB in size, and then reconfigured logrotate to keep the log file sizes down. Everything was fine until days later the deleted file was somehow reclaimed by the Passenger processes (as revealed by lsof +L1). It appears the deleted file increases in size so apparently it's being written to. I'm not sure why it's wanting to write to error.log.1 either, since that's a rotated log file (although it's been so long I'm not sure if I renamed error.log to error.log.1 when I was deleting/moving things around and that may be somehow related to the problem) Restarting passenger via touch tmp/restart.txt didn't change lsof +L1 nor reclaim the disk space but restarting nginx did.
Now the really weird part is that the system has been rebooted since then and the problem still occurs. Some days or weeks pass and then suddenly the available disk space shrinks, I check lsof +L1 and there's the deleted file again. What on earth could be going on here? It would be interesting to know how this happened and helpful to know how I might be able to stop it from recurring. Thanks.

the log rotate conf looks like this:
/var/log/nginx/*.log {
daily
missingok
rotate 52
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 cat /var/run/nginx.pid
endscript
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

遗失的美好 2024-12-21 02:47:05

我知道这是一个旧线程,但我的猜测是 nginx 服务重新启动,这释放了已删除日志文件上的锁定,因为“可用磁盘空间突然缩小”(如果您删除了一个具有打开句柄的文件,它将表现出您所描述的行为,直到该句柄被释放)。听起来 logrotate 函数不会导致 nginx 释放句柄?

I know this is an old thread, but my guess is the nginx service restarted which freed up the lock on the deleted log file, for the 'suddenly free disk space shrinks' (if you delete a file which has an open handle to it, it will exhibit the behavior you describe, until that handle is released). It sounds like the logrotate function isn't causing nginx to release the handle?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文