Ok, so I'm trying to empty a file. It's a text log file, which is being written continuously. My ls -lh says it's 3GB

I run

 > file.log

My ls -lh says it's still 3GB

However the size of the folder containing this file is 3GB less. Weird enough, counting the lines says it's not empty, and i cannot open it with vim (too big).

I don't have admin access however i am the owner of the file.

I tried to create a new file with only the first line to see what's going on

head -1 file.log > first_line.txt

And the first_line.txt is 3GB. This is indeed an weird behaviour.

Question 1: Why is my first command not emptying the file?

Question 2: How can i empty the file without deleting it?


EDIT after comments: the file is being open and written by other processes, continuously.

Sadly i cannot interfere with those processes, so i cannot temporarly quit or restart them

  • 1
    Did you try to write sync after your attempts ? Is there any process still working on it? What says file file.log ? PS> Welcome on Super User :-)
    – Hastur
    Feb 2 '16 at 14:45
  • Thanks for the welcome! I should have been more clear: the file is being open and written by a process. Thesync shows no success. file answer with data Feb 3 '16 at 16:57

your file is being held by a process, you cannot delete it.

use lsof file.log to know which process is writing to it.


mv file.log old.file.log

restart the process. (this depend on process).

next, you will be able to delete old.file.log.

If your file id listed in /etc/logrotate.d/* you can issue a logrotate command.

  • Thanks for the hint, however i am not be able to restart the process. Is there a way to empty the .log without interfering with the process which opens it? Feb 3 '16 at 16:59
  • if process/program holding the file has no way to reset log (by a kill -XX PID) I see no way.
    – Archemar
    Feb 3 '16 at 20:04

To (almost) empty the file, use the command

echo "" > file.log

Or, if your OS has it,

truncate file.log --size 0

Will truncate it to 0 bytes.

If the file does not have any linefeeds, it is possible that the entire file is 1 line long, explaining a 3 gig file.

You can grab a sample of the file using the command like

dd if=file.log of=firstpart.txt count=1 bs=200

Which will take the first 200 bytes of the file. (If you need more, increase the "bs" parameter up to 4096, if you need more then that, use the count parameter, ie to get 8192 blocks, count=2 bs=4096)

@Archemar advice is good, but I'm not sure it answers your questions.

  • There’s generally no need to split the block size like that, especially with values that low.
    – Daniel B
    Feb 2 '16 at 20:28
  • Yup. Agreed, but its a good idea to get the logic correct, particularly if one is going to start moving large chunks of data around.
    – davidgo
    Feb 3 '16 at 0:52
  • Weird enough, the size 3GB file gets generated no matter which line i chose to copy (so it's not all in the first line). Anyway, not the > nor the truncate do manage to empty the file. Updated quest description: the file is being open continuously by another process. Maybe is that one preventing? Feb 3 '16 at 17:05
  • If the file is being held open, that would be preventing the removal of the file. Are you sure there is no signal you can send to the open program to tell it to close and reopen the file ? (This would be pretty standard functionality)
    – davidgo
    Feb 3 '16 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.