Server is Ubuntu 16.04. I have a process running with nohup that logs into a local file. This file gets big enough to consume 100% disk space. To resolve this I have to kill the process first and then remove the log file. Then I restart the process. How can I resolve this with a script or some other tool?

3 Answers 3


With logrotate you can configure how big a log file may get or after how much time:

  • the log files are rotated (log.n becoming log.n+1, and the last log file being deleted)

  • the current log file is truncated without disturbing the writing process.

Take a look at man 8 logrotate.

  • Maybe this would have worked if the file wasn't open at the time i run logrotate. It tries renaming the file and fails. nohup keeps streaming data into the log file. So i guess it must be open all the time.
    – DEVCNN
    Apr 2, 2019 at 8:12
  • 3
    @DEVCNN You are learning why using standard output and redirecting it to a log file is just about the worst possible approach to logging. Your log file is tied to the logging process, and you can't do anything about it. The actual solution is to use a proper logging system that would allow you to separate the actual log file from the process and allow you to use tools like logrotate. There are a lot of really good reasons things like syslog and logrotate exist - and you're learning a lot of them. Apr 2, 2019 at 11:42
  • Sure. I'll look into that.
    – DEVCNN
    Apr 2, 2019 at 13:01

I guess that you start the script/program with nohup like

nohup scriptname 1>logfile.log 2>& &

I would recommend instead of deleting the log file just to clear it with

echo -n >logfile.log

If you delete/move an open file it will be written until the process will close the file or the process will end.

  • Solves my problem. Thanks.
    – DEVCNN
    Apr 2, 2019 at 8:02
  • Useless use of echo. Just >logfile.log Apr 2, 2019 at 10:36
  • using "echo" doesn't hurt. it's build-in
    – 0x0C4
    Apr 2, 2019 at 10:38
  • 2
    This is an extremely unreliable way to free disk space from a full log file. The process writing to the log file has a current offset, and truncating the file with > doesn't change that offset. The next time the file gets written to, you'll likely get either a sparse file if the underlying filesystem supports sparse file, or you'll wind up with a file the same size, almost entirely full of \0/NUL characters and taking up the same amount of space. Apr 2, 2019 at 11:39
  • 1
    @AndrewHenle this answer is simply wrong since the shell is being used for redirection. However, if the redirection is changed to >> then it works because the log file is opened with O_APPEND. See unix.stackexchange.com/questions/202797/…. In general though, your warning is correct. All log files should be opened with O_APPEND to make rotation easy but alas some programs don't do that. Apr 2, 2019 at 18:14

To delete all logs automatically, edit the .bashrc file using your favorite text editor. Here I'm using nano. In your terminal run:

nano ~/.bashrc - 

Add the following to the bottom of the file:

rm -r /var/log   # Deletes logs directory
clear            # Clear the terminal

Press Ctrl+O to save and Ctrl+X to exit edit mode.

The .bashrc file is executed every time you log in or launch a terminal instance, thus your logs will always be deleted.

You can also delete them based on time. E.g. delete all logs created 3 days ago using:

find /yourlog/path -mindepth 1 -mtime +3 -delete
  • -mindepth 1 means process all files except the command line arguments.
  • -mtime +3 will check for the files that were modified 3 days ago.
  • -delete will delete them.

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.