这是一个创建于 1527 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个奇怪的问题，在线上服务器使用 echo > stdout.log 清理日志，可以释放 df 和 du 的空间，但是 ll -h 显示的问题还是没有缩小，该文件不能使用 grep 、sed 、head 这些命令处理了，会卡住。使用 tail 或者 vim 跳转到最后也是可以的。文件写入很快，操作系统是 Ubuntu 18.04.3，文件是 java print 的重定向。只有线上环境出现了这个问题。感觉和日志写入速度有关系。
 |
1
CallMeReznov 2020-10-23 15:15:19 +08:00
得先停止之前操作这个文件的进程,然后才能真正的"释放"
用 lsof 看一下就知道了 |
 |
2
arloor 2020-10-23 15:40:22 +08:00
1 楼正解
|
 |
3
zqyisasd OP 是的，是进程占用了。重启进程可以解决。不过就是每次都是要重启才能释放，在别的环境没有这种问题。感觉很奇怪。
|
|
4
CallMeReznov 2020-10-23 16:15:17 +08:00
一般日志都有一个截断的操作,一般为天,巨大的为小时,分钟等.
|
|
5
zqyisasd OP echo > stdout.log 截断日志，即使是日志很小也不能成功。日志写入很慢的开发、测试环境都是正常截断的。因为这个是 java -jar > logs/stdout.log, 所以项目也不能处理这个文件。
|
 |
6
yanqiyu 2020-10-24 00:58:54 +08:00
用 `truncate -s 0` 清空看看
不过既然 df 都提示空间释放了，我猜空间是真的释放了 ls -lh 的输出可能是撞上了 bug |
|
7
yanqiyu 2020-10-24 01:06:19 +08:00
@zqyisasd 才读到这一条，换用 >> 来重定向到日志试一试，理论上这样才能保证打开文件用了 O_APPEND 属性，从而使得 > 清理文件好用
|
|
8
zqyisasd OP @yanqiyu 不只是 ll -h, 文件本身的头部也损坏了。文件在>清空时候，同时有大量新的内容写入，估计造成了这个 bug 。
|
|
9
zqyisasd OP 除了重启进程和使用 rsync，这些可以释放文件。目前测试其他的方法都不好使。使用 rsync 后 java 进程不再向文件输入内容。
|
|
10
zqyisasd OP 在文件写入比较慢的时候，truncate -s 0 stdout.log 是有效的
|
|
11
yanqiyu 2020-10-27 20:23:47 +08:00
那就考虑这个 https://man7.org/linux/man-pages/man1/split.1.html
用法： somecommand | split -l <合适的截断行数> --filter='gzip > $FILE.gz' - <输出文件名前缀> 就能实现日志自动分割与存档 |
Select Language