I have two files, each one contain more than 3GB in /var/log partition, I need to free some space without deleting or moving the files cause it will interrupt my system.

I also can't delete the lines in files with vi + dd. There are thousands of lines.

Any useful ideas?


1- messages

2- My web server log file.

  • why not just rotate/gzip those? – tonioc Jan 8 '18 at 8:19
  • 1
    Logrotate will gzip the file it does't need any extra space. it will use new file instead – Mongrel Jan 8 '18 at 8:40
  • 3
    @Mongrel Because gzip writes to a new file it does need additional space. And a lot of it if the file being compressed is large. When gzip is finished you need less space that before it started but that does not help you at all in the meantime. – Hauke Laging Jan 8 '18 at 8:43
  • 1
    @Mongrel That is not what my version (gzip 1.8) does. With a quick look I did not notice any option in the man page to activate such behaviour. – Hauke Laging Jan 8 '18 at 9:44
  • 1
    @Mongrel gzip does not use /tmp as a workspace. It creates (and writes) the compressed file to the same location in the filesystem as the file being compressed. To get around this one would have to use a pipe-and-move solution. – roaima Jan 8 '18 at 11:02

You may be able to truncate the files, which unlike using rm will release the disk space even if the files are still open:

> /var/log/big1.log
> /var/log/big2.log

But please test it on a separate system first. Check if the file's inode numbers change. If not, you're good.

  • @roaima I don't see where OP asks for compression. In any case, he can save the current contents elsewhere, before truncation. I checked with a file open for writing, space was freed. – Gerard H. Pille Jan 8 '18 at 11:14
  • @roaima no problem. Again, I verified what I said. You are referring to the deletion of a file that is open. That is not what the shell does with ">". – Gerard H. Pille Jan 8 '18 at 11:35
  • @roaima That's what mondays are for. – Gerard H. Pille Jan 8 '18 at 11:55
  • This completely remove the contain of the file,i tested this then i applied this only on messages after backing up my file. – BOUKANDOURA Mhamed Jan 9 '18 at 8:50
  • 2
    That is indeed what I meant by "truncate". You should now implement log rotation to prevent this from happening again. – Gerard H. Pille Jan 9 '18 at 9:05

If you want to keep the full content of the existing files you will need to compress them to some temporary space elsewhere and then replace each uncompressed file with its compressed equivalent. Otherwise just delete the older log files or archive them elsewhere.

Here is a proposal to compress the log files without losing their contents. However, you need to be aware that if you keep growing log files it will only defer the problem of your filesystem filling up and not resolve it permanently.

Identify the older files that are to be compressed. (None of these must be in use or open right now for logging.) In my example this is big1.log.

Identify a chunk of filesystem that can hold the largest of these uncompressed files. In my example I'm going to assume this is /home.

In your real-world scenario you can use a for loop to iterate across a series of files. Here are the steps for a single file:

logfile='/var/log/big1.log'                      # The logfile to be compressed

if gzip -c "$logfile" >/home/log.gz
    touch --reference "$logfile" /home/log.gz    # Capture timestamp of last update
    chown --reference "$logfile" /home/log.gz    # Capture ownerships
    chmod --reference "$logfile" /home/log.gz    # Capture permissions
    rm -f "$logfile"                             # Make space
    mv -f /home/log.gz "$logfile.gz"             # Rename with correct suffix

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.