[Top][All Lists]

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

Re: tail --retry not re-attempting to open file

From: Pádraig Brady
Subject: Re: tail --retry not re-attempting to open file
Date: Wed, 17 Apr 2013 15:31:50 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 04/17/2013 06:39 AM, Bernhard Voelker wrote:
> On 04/04/2013 03:42 AM, Pádraig Brady wrote:
>> I've nothing against simplicity though since the
>> inotify code already deals with missing files when
>> following by name, by watching the parent dir,
>> it might be easy to adjust to handle this case.
> Hi Padraig,
> sorry for the late reply.

Thanks for the update.
Will review ASAP.

> After all, I think tail.c is not in a very good, maintainable shape.
> There are so many knobs, partially with overlapping meaning like
> 'follow_mode' vs. 'forever', or 'reopen_inaccessible_files' vs.
> f[i].ignore etc., that it's rather hard to do the right change
> without breaking something else.

I agree that the current inotify functionality isn't ideal.

inotify advantages
 immediate output of changes
  (but one can always use -s.1)
 could be used to watch *.log in a local directory
  (but we don't currently leverage inotify to provide this functionality)

inotify disadvantages
 not used for stdin
 can't be used for remote files
 doesn't work for remounts
 only works on linux
 more complicated

Also in the meantime the more encompassing fanotify Linux API
has become available which might simplify implementation
and/or provide new functionality.

At this stage I wouldn't be on for removing the current
inotify implementation, but also I wouldn't be enthused about
adding any large refactoring or new functionality based on it.
Any large changes (like supporting watching any new files in a dir for e.g.)
should probably consider using fanotify or some other mechanism instead.


reply via email to

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