Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I am writing a perl script that looks for log files on a linux system (for deletion and/or log rolling). I'm using File::Find::Rule. However, I don't want to touch files with any open file handles.

what's the best way to go about this? Would simply pulling atime in the past do the trick, or is there some other way?

Thanks

  • Comment on Looking for log files with open file handles in linux.

Replies are listed 'Best First'.
Re: Looking for log files with open file handles in linux.
by davido (Cardinal) on Jul 13, 2011 at 19:44 UTC

    To avoid tromping on a file that is open for output elsewhere, as well as to avoid someone else tromping on your file, you can use flock. And to avoid race conditions, you open, flock, work, unlock, close. In other words, it's not safe to open, test the lock, close, and then later assume that you can re-open and work on the file. By then the file could be used elsewhere.

    One issue that is not an issue is unlocking before closing. One might think that since close flushes the file handle one final time, any buffered output might get written after the unlock. Perl deals with this for you by flushing the filehandle upon unlocking. Be sure to read the docs on flock. Locking is tricky, and has to be done right.

    Of course this is assuming that other processes are actually locking their logfiles, as they ought to. Well behaved programs will, but there's no guarantee that everything you're looking at is well behaved.


    Dave

Re: Looking for log files with open file handles in linux.
by MidLifeXis (Monsignor) on Jul 13, 2011 at 19:29 UTC

    Would fuser do the trick?

    --MidLifeXis

Re: Looking for log files with open file handles in linux.
by jpl (Monk) on Jul 14, 2011 at 09:26 UTC

    If you delete via unlink (as opposed to truncation, for example) and roll via rename (not by copying), you may not have to worry. If you unlink a file that another process is reading, the file will continue to exist until the other process closes the file. This is the basis for an old trick of opening, then unlinking, a file, so it will "disappear" even if the machine crashes. The file can be written and read using the open file handle, even though it has no visible presence in the file system. Similarly, a file that is being appended to by another process can safely be renamed within the file system. The open file is "known" by its inode number, not by the name by which it was opened, and the inode number is unaltered by a local rename.

    Don't rely on atime. Many, perhaps most, linux file systems no longer maintain it.