Reputation: 12983
Issue is, all the below listed commands make the file size 0 (Zero) but for some time.
When the new logs are generated then log file size is = old file size(before truncate) + new log messages size.
This means that truncate does not free the disk space occupied by the file.
File size should be whatever the size of new log messages those are coming after truncate command.
I have tried below options before asking this question.
- $ > sysout.log
- $ : > sysout.log
- $ cat /dev/null > sysout.log
- $ cp /dev/null sysout.log
- $ dd if=/dev/null of=sysout.log
- $ echo "" > sysout.log
- $ echo -n "" > sysout.log
- $ truncate -s 0 sysout.log
At first, I checked the file size (contains 10 lines of log messages)
[root@mylaptop ~]# ls -lh sysout.log
-rw-r--r-- 1 root root 6.0K Dec 2 11:30 sysout.log
Then ran the truncate command
[root@mylaptop ~]# truncate -s0 sysout.log
[root@mylaptop ~]# ls -lh sysout.log
-rw-r--r-- 1 root root 0 Dec 2 11:31 sysout.log
After few seconds 2 lines of log messages printed into the file. But file size is
[root@mylaptop ~]# ls -lh sysout.log
-rw-r--r-- 1 root root 6.3K Dec 2 11:31 sysout.log
As you can see, it adds the file size.
How to free the disk space? Or is there any another approach?
Upvotes: 0
Views: 1837
Reputation: 14452
For long running processes that open the file for write mode (using '>', or otherwise), the process tracks the offset of the next write. Even if the file size is truncated to 0, the next write will resume at the last location. Most likely, based on description is that the long running process continue to log at the old offset (effectively leaving lot of zero-byte data in the start of the file.
Solution is simple, instead of logging in write
mode, use append
mode.
# Start with a clean file
rm -f sysout.log
# Force Append mode.
java - jar my_app.jar >> sysout.log 2>>&1 &
...
truncate ...
# New data should be written to the START of the file, based on truncated size.
Notice that all writing processes, and connections should use append
mode.
Upvotes: 2