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

[Bernhard Voelker]

re-adding the list.

On 04/03/2013 05:12 AM, Noel Morrison wrote:
> Sorry to inform you but in the standard tail command even if a file is
> not present, the tail -f --retry would retry at some interval to attach
> to the filename . If the file would become present or readable it would
> at that time open and start following the appended results. I can show
> proof of the command and its results. Please check this out on any 5.x
> RHEL System, that uses the standard tail. I've not checked my debian box
> at the house. Maybe this is a difference on how GNU handles it, but in
> my experience with tail this --retry is not performing as expected.

Oooh - I tested on RHEL 5.4 with coreutils-v5.97, and it's true:
tail -f --retry continues to try to open the given file there
while tail from latest Git (or 8.21) does not.

There is no obvious commit regarding this, but this seems to be
related with the inotify support. As inotify_watch() does not
succeed (because of ENOENT), tail terminates.
If tail is forced to revert to polling, e.g. by the (undocumented)
---disable-inotify option, then tail will start to try opening the
file again and therefore waits until the given file name appears.

Furthermore, I find this warning irritating
  "warning: --retry is useful mainly when following by name"
because for polling, this option really makes sense
... and a difference: if --retry is specified, tail would retry
to open the file while it would not otherwise. Or the other way
round: --retry may only not be useful together with inotify.

I don't know if this behavior is intended.
Others?

Have a nice day,
Berny