4

If a log file such as nohup.out is deleted in Linux while it is still the subject of a running job (and further input) what happens to the data?

eg

script.sh

#!/bin/bash
while [ 1 ]
do
  fortune
done

then...

# nohup ./script.sh &

This outputs the log to nohup.out by default.

Or even

# ./script.sh > nohup.out &

The question is; if nohup.out is deleted what happens? Is the file really gone assuming the job continues? What happens if script.sh generates enough data to fill a disk? Does this create a de-facto state of redirection to /dev/null?

By way of background I have found a process started previously in this method that can not be restarted for an extended duration but prior to that maintenance window it is my estimation the disk will fill. The situation will be avoided in the future, I am just curious as to what happens to an unlinked file still subject to redirection.

1 Answer 1

8

If a program still has a file handle open, what I believe will happen is that the file continues to exist. It disappears from your directory listings and looks gone but until the last file handle is closed the file continues to grow.

This is why people will have huge files on the filesystem and get errors, find an errant file that is huge, delete it, and still have huge disk space listings but cannot find the file anymore. It's there. Just not quite visible. Use lsof to find the application holding the file handle and kill/close the application then the space is reclaimed.

3
  • I suspected as much but wasn't incredibly sure about that been the case. Interesting point about lsof to find them, regardless they will be permanently unlinked when that process dies... I think. At the end of this day I just used "echo > nohup.out" which reset the file back to 0 but didn't break the handle which solved the expansion without leaving a ghost file around that would continue to grow.
    – Antitribu
    Oct 14, 2009 at 11:52
  • It's a common issue for new admins especially. Look around on SF for questions related to disk use and the DF and DU command and why they're not consistent. This seems inevitably to be related to the answer, especially when it's saying the filesystem is 102% full :-) Oct 14, 2009 at 11:56
  • another hint is to look at /proc/**pid**/fd. You should see symlinks from a numeric filename (representing the file handle number inside your app) to the actual file name. Deleted files have a literal "(deleted)" string at the end of the name. Oct 19, 2009 at 17:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .