有个奇怪的问题，在线上服务器使用 echo > stdout.log 清理日志，可以释放 df 和 du 的空间，但是 ll -h 显示的问题还是没有缩小，该文件不能使用 grep 、sed 、head 这些命令处理了，会卡住。使用 tail 或者 vim 跳转到最后也是可以的。文件写入很快，操作系统是 Ubuntu 18.04.3，文件是 java print 的重定向。只有线上环境出现了这个问题。感觉和日志写入速度有关系。

得先停止之前操作这个文件的进程,然后才能真正的"释放"
用 lsof 看一下就知道了

1 楼正解

是的，是进程占用了。重启进程可以解决。不过就是每次都是要重启才能释放，在别的环境没有这种问题。感觉很奇怪。

一般日志都有一个截断的操作,一般为天,巨大的为小时,分钟等.

echo > stdout.log 截断日志，即使是日志很小也不能成功。日志写入很慢的开发、测试环境都是正常截断的。因为这个是 java -jar > logs/stdout.log, 所以项目也不能处理这个文件。

用 `truncate -s 0` 清空看看
不过既然 df 都提示空间释放了，我猜空间是真的释放了 ls -lh 的输出可能是撞上了 bug

才读到这一条，换用 >> 来重定向到日志试一试，理论上这样才能保证打开文件用了 O_APPEND 属性，从而使得 > 清理文件好用

不只是 ll -h, 文件本身的头部也损坏了。文件在>清空时候，同时有大量新的内容写入，估计造成了这个 bug 。

除了重启进程和使用 rsync，这些可以释放文件。目前测试其他的方法都不好使。使用 rsync 后 java 进程不再向文件输入内容。

在文件写入比较慢的时候，truncate -s 0 stdout.log 是有效的

那就考虑这个 https://man7.org/linux/man-pages/man1/split.1.html
用法：
somecommand | split -l <合适的截断行数> --filter='gzip > $FILE.gz' - <输出文件名前缀>
就能实现日志自动分割与存档