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

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

From: Pádraig Brady
Subject: Re: tail --retry not re-attempting to open file
Date: Wed, 03 Apr 2013 12:02:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 04/03/2013 09:42 AM, Bernhard Voelker wrote:

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 inotifywatch() 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.

Yes I agree that this is a regression associated with the inotify support. I take tail --follow=descriptor --retry to mean, Wait for the file to appear initially and follow even if renamed or unlinked.

Furthermore, I find this warning irritating "warning: --retry is useful mainly when following by name"

I agree. It's not imparting much info, about why that's supported. What we should do is print what tail will do in this case. I propose we do:

if (retry) if (!follow_mode) warn ("--retry ignored"); else if (follow_mode == DESC) warn ("--retry only effective for the initial open");

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 couldn't really follow (pardon the pun) what you were saying there. But there should be no functional difference between polling and inotify, only timing and efficiency differences.

thanks, Pádraig.