To reproduce the problem, you can run this script. It exhausted inotify watches. (in order to get the result more quickly, decrease the value of max_user_watches.)
let count=0; echo $count>>a.log; ./tail -F a.log & while true; do mv a.log a.log.$count; let count=count+1; echo $count>>a.log; done I tested this problem in coreutils 8.4 and 8.23. 2015-02-03 20:16 GMT+09:00 Pádraig Brady <[email protected]>: > On 03/02/15 07:26, 최종우 wrote: > > 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? > > I don't see where we leak watch descriptors, and if we run out of resources > we should revert to polling mode. Can you reproduce the problem with > tail built from the coreutils 8.23? > > wget ftp://ftp.gnu.org/pub/gnu/coreutils/coreutils-8.23.tar.gz > tar -xf coreutils-8.23.tar.gz > cd coreutils-8.23 > ./configure --quiet && make > > you can then use src/tail for testing. > > What are the exact steps to reproduce if 8.23 has the issue? > > thanks, > Pádraig. > >
