nothing wrong with unlinking open files, they just hang
around to some extent until they're closed. I don't think
it's anything to worry about, although it might be odd that
something is holding it open after deletion for a very long
time... What is pid 380?
-Eric
On Sat, 27 Mar 2004, Jason White wrote:
> Iustin Pop writes:
> >
> > More exactly, do a:
> > lsof +L1
> > and see if any /var/log/ files show up in this - it lists files deleted
> > but still in use - for those Unix won't free space until after they are
> > closed.
>
> Could this be responsive for the unlinked inode of a cups log file
> that I recovered, and reported on the list, a few weeks ago? Running
> the above command today I find:
> lsof +L1
> COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME
> cupsd 380 root 1u REG 3,5 7250 0 71364886
> /var/log/cups/error_log.1 (deleted)
>
> What's the exact sequence of events leading to filesystem corruption?
>
> 1. File is open and written to.
> 2. File is unlinked while open.
> 3. File is closed (unlinked inodes?)
> 4. Alternatively, system crash before close (unlinked inodes?).
>
> Is this entirely a userspace problem (i.e., files shouldn't be
> unlinked while open) or is it a Linux or XFS bug? I would say anything
> resulting in unlinked inodes requiring recovery should be prevented at
> the operating system level, if possible, unless there are good reasons
> to the contrary.
>
>
|