I've just found the following thread: http://lists.gnu.org/archive/html/bug-coreutils/2009-06/msg00148.html
It looks like the same situation I've encountered. But I couldn't reproduce the result of that thread. Is it related to my problem? 2015-01-23 22:14 GMT+09:00 Pádraig Brady <[email protected]>: > On 23/01/15 07:51, 최종우 wrote: > > I am using GNU coreutils 8.4 with flume 1.4.0, log4j 1.2.17. > > > > I've found a problem that sometimes tail run by flume is reading a file > has been renamed by log4j. > > > > flume executed tail with following parameters: > > tail -F logfilename > > > > Fist flume had run the command, I checked file descriptors opened by > tail process: > > ls -l /proc/pid/fd > > > > 0 -> pipe:[185694192] // Sorry, I am not sure that the numbers are > correct. > > 1 -> pipe:[185694193] > > 2 -> pipe:[185694194] > > 4 -> inotify > > 5 -> logfilename > > > > After time passed, log4j had rotated the log file, I rechecked file > descriptos: > > ls -l /proc/pid/fd > > > > 0 -> pipe:[185694192] // Sorry, I am not sure that the numbers are > correct. > > 1 -> pipe:[185694193] > > 2 -> pipe:[185694194] > > 4 -> inotify > > 5 -> logfilename.1 > > > > > > tail has been being executed with a parameter '-F', but didn't follow by > name. > > This problem doesn't happen always. I don't know why this problem > happened. > > There have been many fixes to tail since version 8.4 (5 years old). > In particular, that version of tail would not notice changes to files > on remote file systems. What file system are you using? > I'd encourage you to test with a later version if possible. > Also I'd try using the undocumented ---disable-inotify option > (note the 3 dashes) to see if inotify is to blame. > > thanks, > Pádraig. >
