On Tue, Feb 21, 2006 at 03:25:08PM -0500, Uri Guttman wrote: > because of how inodes were created you can't watch mtime or size and > guarantee you have new data to read. one very bizarre corner case is > when the log file is overwritten with the exact same size of text as it > previously had. then the mtime has changed but you have no clue as to > where to read from as the size is the same. if the file was rotated then > you can see a new inode number and use that to start seeking from the > beginning. i don't think the unchanged counter thing is a good > idea as some log files may be dormant that long. > > another issue is should you keep a handle open between tail polls or > open it fresh each time? since my code checks the inode number, opening > each time makes more sense.
If you keep it open, that guarantees that a new file will have a different inode number (on any kind of file system that follows the traditional Unix conventions at least - toy file systems from Redmond might be inadequate to this task), since the old file will still exist (even if it has been deleted during the rotation process, the continued open file descriptor means it hasn't yet completely gone). Even if you didn't do that to force the inode change, you can still tell whether the file has been cycled (even it the new one is back to the same size) by seeking backwards a bit and re-reading the last text you pulled in and comparing to make sure it is still the same. (This does assume that log file entries have a timestamp or some other component that will make an adequately long text segment certain to never be exactly duplicated in a subsequent log entry.) Of course, detecting that a log switch of some sort has occurred doesn't ensure that you will be able to tell if more than one has occurred "very quickly" (from your frame of reference - that might mean that your tailing program got paused for a long time instead). -- _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
