我已经rm编写了一个2.5gb的日志文件 - 但它似乎没有释放任何空间.
我做了:
rm /opt/tomcat/logs/catalina.out
这个:
df -hT
并df报告我的/opt坐骑仍然100%使用.
有什么建议？
重新启动tomcat,如果文件正在使用中并且您将其删除,则该进程完成后该空间将变为可用.
正如其他人所建议的那样,该文件可能仍被其他进程打开.要找出哪些,你可以做
lsof /opt/tomcat/logs/catalina.out
它列出了进程.可能你会在该列表中找到tomcat.
可能正在运行的程序仍然保留文件.
根据这里的其他答案,您可以简单地关闭tomcat以阻止它保持文件.
如果这不是一个选项,或者您只是想要更多详细信息,请查看以下问题:查找并删除已打开但已被删除的大型文件 - 它建议采用一些更恶劣的方式来处理它,这对您的情况可能更有用.
linux/unix文件系统认为"已打开"的文件是他们的另一个名称.rm从目录树中看到的文件中删除"名称".在句柄关闭之前,文件仍有更多"名称",因此文件仍然存在.文件系统在完全未命名之前不会收集文件.
这可能看起来有点奇怪,但这样做可以实现启用符号链接等有用的东西.符号链接基本上可以视为同一文件的备用名称.
这就是为什么如果你完成它,总是在文件句柄上调用你的语言等同于close()是很重要的.这通知操作系统不再使用该文件.虽然有时候这种情况无法得到帮助 - 但Tomcat可能就是这种情况.请参阅Bill Karwin的答案以了解原因.
根据文件系统的不同,这通常作为一种引用计数实现,因此可能不涉及任何实名.如果stdin和stderr之类的东西被重定向到文件或其他字节流(最常见的是服务),也会变得奇怪.
这整个想法与' inodes ' 的概念密切相关,所以如果你是好奇的类型,我建议先检查一下.
它不再工作得那么好了,但是你曾经能够更新整个操作系统,使用新的库启动一个新的http-daemon,最后在没有更多的客户端为它提供服务时关闭旧的一个(发布)旧手柄).http客户端甚至不会错过任何一个节拍.
基本上,您可以完全消除内核以及"从下面"运行程序的所有库.但由于旧版本的"名称"仍然存在,因此该文件仍存在于该特定程序的内存/磁盘中.然后,这将是重新启动所有服务等问题.虽然这是一个高级使用场景,但这是一些unix系统记录多年的正常运行时间的原因.
重新启动Tomcat将释放Tomcat对该文件的任何保留.但是,为了避免重新启动Tomcat(例如,如果这是一个生产环境并且您不想不经意地关闭服务),通常只能覆盖该文件:
cp /dev/null /opt/tomcat/logs/catalina.out
甚至更短更直接:
> /opt/tomcat/logs/catalina.out
我始终使用这些方法在故障排除或磁盘清除过程中清除当前正在运行的服务器进程的日志文件.这会留下inode,但会清除实际的文件数据,而尝试删除文件通常不起作用,或者至少会混淆正在运行的进程的日志编写器.
正如FerranB和Paul Tomblin在此线程中所指出的那样,该文件正在使用中,并且在文件关闭之前不会释放磁盘空间.
问题是你不能发信号通知Catalina进程关闭catalina.out,因为文件句柄不受java进程的控制.catalina.sh当你启动Tomcat时,它是由shell I/O重定向打开的.只有通过终止Catalina进程才能关闭该文件句柄.
将来有两种解决方案可以防止这种情况:
不允许来自Tomcat应用程序的输出catalina.out.而是使用该swallowOutput属性,并为输出配置日志通道.可以在不重新启动Catalina进程的情况下轮换log4j管理的日志.
将catalina.sh修改为管道输出到cronolog而不是简单地重定向到catalina.out.这样cronolog会为你旋转日志.
最好的解决方案是使用'echo'（作为@ejoncas'建议）：
$ echo '' > huge_file.log
此操作非常安全且快速（每秒删除约1G数据），尤其是在生产服务器上运行时。
不要简单地使用“ rm”删除此文件，因为首先您必须停止写入该文件的过程，否则将无法释放磁盘。
请参阅：http：//siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production
京公网安备 11010802040832号 | 京ICP备19059560号-6 