We have an apache server running on linux writing to a log file that is getting really large (access_log). Our server will begin running out of space. Is there a way to delete or truncate the file without restarting the server (we don't want any down time).


How to reset your log files

Sooner or later, you'll want to reset your log files (access_log and error_log) because they are too big, or full of old information you don't need.

access_log typically grows by 1Mb for each 10,000 requests.

Most people's first attempt at replacing the logfile is to just move the logfile or remove the logfile. This doesn't work.

Apache will continue writing to the logfile at the same offset as before the logfile moved. This results in a new logfile being created which is just as big as the old one, but it now contains thousands (or millions) of null characters.

The correct procedure is to move the logfile, then signal Apache to tell it to reopen the logfiles.

Apache is signaled using the SIGHUP (-1) signal. e.g.

mv access_log access_log.old
kill -1 `cat httpd.pid` 

Note: httpd.pid is a file containing the process id of the Apache httpd daemon, Apache saves this in the same directory as the log files.

Many people use this method to replace (and backup) their logfiles on a nightly or weekly basis.


  • 2
    What about logrotated ? – LiraNuna Oct 5 '09 at 19:38
  • I can't find the file httpd.pid in /var/log/httpd, any ideas? – erotsppa Oct 5 '09 at 19:57
  • Not sure.. Have you done a directory search? – madcolor Oct 5 '09 at 20:07
  • I see this method "mv & sighup" in a lot of backup scripts. Sometimes there are two outer commands: a pre "stop daemon xxx" ... and post "start daemon xxx". Are these commands useful or useless? – Massimo Jun 8 '19 at 9:47

Zero the logfile...

# :>filename
  • doesn't this require your user to have write access to the log file? Generally that's not the case... – drevicko Jun 26 '13 at 8:04
  • 1
    Based on the prompt, I'd say that he's logged in as root. – Ladadadada Jun 26 '13 at 9:23

log rotation is the long-term solution but the answer to your immediate question is to truncate the file something like this:

sudo cat /dev/null > /var/log/httpd/access_log

i'm assuming you're not logged in as root and assuming the location of your log file but you should be able to adjust the command as needed and quickly truncate an open log file w/o touching your running apache processes.

  • 3
    at least on my ubuntu 12.04 that doesn't work: the sudo applies to cat, but NOT to the file redirection. I used to sudo truncate -s0 logfile. – drevicko Jun 26 '13 at 8:03
  • to avoid cat abuse: echo > /var/log/httpd/access_log – code_monk Mar 16 '17 at 21:20
  • 1
    Truncating is not guaranteed to work. It might work if the process has the file open in append mode. If the file isn't in append mode, the next time the process writes to the file, it will write data at whatever the current offset is, which is probably the length of the file prior to truncation. So you're likely to wind up with a file of the same size, but with all the preexisting data replaced with 0-valued bytes (and if the file is large, that can take some time...). If you're lucky, the underlying filesystem supports sparse files and the 0 bytes don't take up any actual disk space. – Andrew Henle Feb 15 '18 at 10:56

If you want to truncate/zero a log file to which you don't have write access, you can do

sudo truncate -s0 logfile
  • truncating the file doesn't work – c4f4t0r Feb 23 '15 at 15:08
  • @c4f4t0r can you elaborate? – drevicko Feb 24 '15 at 23:55

Try using logrotate

  • it is a powerful tool which gives configurable options for rotating logs.
  • it also has facility to run command during prerotate and postrotate
  • copytruncate enables you to copy existing files and then truncate it. The copy can be moved to another storage such as hadoop, s3 for backup if desired
  • Moreover a cron can be set such as /usr/sbin/logrotate --force /etc/logrotate.hourly.conf 2>&1 >> /tmp/logger by using /etc/cron.hourly/logrotate

For more info man logrotate


Simply you can make first $ cat filename >bkp_filename than it will create copy of "filename" than do nullify original file like $ >filename it will reduce to zero size,now make zip to bkp_filename like $ gzip bkp_filename so it will provide more size and your mount point is green now

  • If you're running out of space, creating a copy of the logfile will likely make the situation worse, rather than better. Additionally please try to format commands by enclosing them in backticks ```. Thanks! – HBruijn Sep 8 '15 at 16:25

Had the same problem with a process and fixed it using Linux named pipe. Here is what I did (assuming /tmp/job.log is the log file):

  1. Stop the job
  2. rm /tmp/job.log
  3. created a named pipe using mkfifo: mkfifo /tmp/job.log
  4. ran: cat /tmp/job.log | gzip > /tmp/job.log.gz
  5. Start the job

This way, I was able to keep the log and reduce the disk usage drastically

you can replace gzip with any command that filters, rotates, ...

  • If /tmp/job.log is held open by the process, rm /tmp/job.log itself not only won't do anything to actually free the disk space the file uses, the process will still write to the now-deleted file. rm only removes the file link from the directory. The file itself won't be deleted and its space freed until the process holding it open actually closes it. – Andrew Henle Feb 15 '18 at 11:01

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.