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: Wed, 03 Apr 2013 10:42:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

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