coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tail is reading already rotated file.


From: 최종우
Subject: Re: tail is reading already rotated file.
Date: Tue, 3 Feb 2015 16:26:13 +0900

tail doesn't release any watch descriptors watching already rotated files except for file deletion. Does it?

In my case, the number of opened watch descriptors exceeded a value of /proc/sys/fs/inotify/max_user_watches and tail was opening a renamed file.
I've tested the following steps.

1) cat /proc/sys/fs/inotify/max_user_watches

2) log files are generated and tail -F the latest log file.

(The number of log files exceeds max_user_watches and tail doesn't print any output to stdout.)

3) ls -l /proc/pid/fd

(tailing already rotated file. It seems that tail couldn't keep track of the lastest file because of a shortage of watch descriptors.)


And I think that the latest revison of tail has the same issue. May I ask you the reason why you don't release watch descriptors for renamed files?

2015-01-23 22:14 GMT+09:00 Pádraig Brady <address@hidden>:
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]