Re: tail --retry not re-attempting to open file (original) (raw)

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

From: Bernhard Voelker
Subject: Re: tail --retry not re-attempting to open file
Date: Thu, 18 Apr 2013 23:52:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

On 04/18/2013 06:10 PM, Pádraig Brady wrote:

On 04/17/2013 06:39 AM, Bernhard Voelker wrote: > Somehow, I don't have a good feeling for using inotify in the > --follow=descriptor case because inotify works with file names. > > Once tail opens the file successfully after inotify says it's > there, tail would have to go back to polling, because all further > inotify events are only relevant for the file name, not the > descriptor. > >From playing with the inotify code, I even had the impression that > there are not all events delivered to tail reliably. Is this true?

I've not noticed such issues TBH. What kernel we you using for reference?

That was when I ran tail via GDB. For the deletion of a file, there usually seem to be 2 events generated (IN_ATTRIB and IN_DELETE_SELF), but while stepping through the code handling the first event, the latter never happened then. That's on a openSUSE-12.1 with: $ uname -r 3.1.10-1.19-desktop

> Additionally to the above, I noticed that tail now would no longer > exit in the case the file appears untailable, e.g. when it appears > as directory. I fixed this, too.

Excellent thanks.

You may want to consider using the existing retrydelay() rather than wait4lines() in the tests, but otherwise it looks good to push.

Thanks for the review. I'll have a look at retry_delay_() again tomorrow, and see if it makes waiting for tail's output easier.

Have a nice day, Berny