coreutils
[Top][All Lists]
Advanced

[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: Thu, 04 Apr 2013 02:42:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 04/03/2013 11:46 PM, Bernhard Voelker wrote:
> Hi Padraig,
> 
> On 04/03/2013 01:02 PM, Pádraig Brady wrote:
>> 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.
> 
> The problem is that tail_forever_inotify() returns false when the
> initial open in tail_file() failed. This makes tail exit immediately.
> Without intense reading of the source, I guess it's not easy to
> use inotify in such a case. Therefore, falling back to polling
> seems to be quite okay.
> The attached patch implement this in a one-liner:

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.
If not I'm fine for reverting to polling.

> @ -2189,7 +2192,8 @@ main (int argc, char **argv)
>           is recreated, then we don't recheck any new file when
>           follow_mode == Follow_name  */
>        if (!disable_inotify && (tailable_stdin (F, n_files)
> -                               || any_remote_file (F, n_files)))
> +                               || any_remote_file (F, n_files)

> +                               || !ok))

I think that needs to be:
  || (!ok && follow_mode == Follow_descriptor)))

>          disable_inotify = true;
> 
>        if (!disable_inotify)
> 
>>> 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");
> 
> I'd go even one step further, and also remove the latter warning.

I'd be 60:40 for keeping the warning as users could
easily specify 'tail -f --retry' not realizing it
wouldn't handle rotated log files for example.

> +# Ensure that "tail --retry --follow=descriptor" waits for the file to 
> appear.
> +# tail-8.21 failed at this (since the implementation of the inotify support).
> +tail -s.1 --follow=descriptor --retry missing >out 2>&1 & pid=$!
> +sleep .2             # Wait a bit ...
> +echo "X" > missing   # ... for the file to appear.
> +sleep .2             # Then give tail enough time to recognize it
> +                     # ... and to output the content to out.
> +kill $pid            # Then kill tail ...
> +wait $pid            # ... and wait for it to complete.
> +rm -f missing || fail=1
> +# Expect 3 lines in the output file ("cannot open" + "has appeared" + "X").
> +[ $( wc -l < out ) = 3 ]   || { fail=1; cat out; }
> +grep -F 'cannot open' out  || { fail=1; cat out; }
> +grep -F 'has appeared' out || { fail=1; cat out; }
> +grep '^X$' out             || { fail=1; cat out; }

This looks racy. There is nothing I see that guarantees that
tail will be scheduled before it's killed.
I'd maybe try something like:

timeout 10 tail .....
until [ $(wc -l < out) = 3 ]; do sleep .1; done
kill $pid
wait $pid

thanks,
Pádraig.



reply via email to

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