Can't reduce log file size with "cat /dev/null"

[jayjayclub]

Hello All

I have a log file which increased file size every 5 seconds but there is no log rotation function with this log file. I want to clean up this log with "cat /dev/null > log_file" but the file size was back to original after next 5 seconds. The application can't be stop. How do I clean up this log file?
Thanks

[James R. Ferguson]

Hi:

You need to fix the application to do less logging or live with a large log file.

Regards!

...JRF...

[Dennis Handly]

>I want to clean up this log with "cat /dev/null > log_file" but the file size was back to original after next 5 seconds.

Unless the application is cooperating, it will continue to write to where it thinks the file pointer is, not back to 0.
The application will have to be rewritten, either to close and open the file or to open it append?

[Hakki Aydin Ucar]

Once upon a time I had a problem like this, a script caused this, even though I did fg there was no background process seemed, and logs were growing and growing immediately.

Solution ,somehow you have to find what is the root cause and decide whether or not stop it,
you can use ps -ef | grep -i
and kill it ,if you can find.

OR use lsof to see if there is open and running script suspected to cause this?

[jayjayclub]

Thanks ! It looks like no other way to rotate this log manually except changing AP. I just wonder if this log really occupies such disk space as it shows or it just a dummy file size.

[James R. Ferguson]

Hi:

> I just wonder if this log really occupies such disk space as it shows or it just a dummy file size.

If you mean is it a sparse file, you could compare the size as seen by 'ls' and 'du'. If the 'du' size (multiplied by 512, since that is the block size unit) is substantially different from a simple 'ls' the file is sparse. If you copy (with 'cp' the file and its size inflates, that's another indication that the file is sparse).

Whether or not the application is creating a sparse file, a shell redirection will truncate it. As Dennis hinted, that doesn't stop the application from seeking to where ever it "thinks" is wants its end-of-file pointer to be before a subsequent write.

Regards!

...JRF...

[Bill Hassell]

> rotate this log manually...

Moving (renaming) a file won't fix the problem until the application closes the file. When the file is open, you even remove (rm) the file and the space will not be reclaimed (and the no-name logfile will continue to grow) until the application stops.

As far as space goes, the ll command (ll /tmp/logfilename) shows allocated (directory entry) space while du (du -k /tmp/logfilename) will show occupied space. Since most logfiles are normally created serially (appended), the occupied and allocated space should be the same.

[TTr]

What is so secret about this app? Maybe someone know the app and can help you more specifically.

[Dennis Handly]

>JRF: that doesn't stop the application from seeking to where ever it "thinks" is wants its end-of-file pointer to be before a subsequent write.

I tried to duplicate this with stdio using several different fopen modes and I wasn't successful.
Perhaps using tusc would tell us if there was a lseek before the write.