Util-Linux package development
 help / color / mirror / Atom feed
From: "Pádraig Brady" <P@draigBrady.com>
To: Ruediger Meier <sweet_f_a@gmx.de>
Cc: util-linux@vger.kernel.org
Subject: Re: tailf, really needed?
Date: Fri, 13 Mar 2015 13:35:26 +0000	[thread overview]
Message-ID: <5502E79E.20605@draigBrady.com> (raw)
In-Reply-To: <201503131402.30431.sweet_f_a@gmx.de>

On 13/03/15 13:02, Ruediger Meier wrote:
> On Friday 13 March 2015, Pádraig Brady wrote:
>> On 13/03/15 09:00, Ruediger Meier wrote:
>>> Hi,
>>>
>>> As far as I understood tailf's advantage over "tail -f" is that it
>>> does not access the file when it does not grow. But nowadays
>>> coreutils "tail -f" also does not seem to access the file. So do we
>>> really need tailf?
>>>
>>> The point is that I've noticed that our tailf fails to deal with
>>> filesystems where inotify is broken. For example it does not work
>>> for overlayfs. coreutils tail code looks quite complicated and
>>> seems to manage such cases. Is it worth to fix our tailf or better
>>> just remove it and use "tail -f"?
>>>
>>> BTW coreutils tail is much more comfortable. It has many important
>>> options. For example watching log files without -F or --retry does
>>> not make sense to me (because of logrotate).
>>>
>>> Last but not least, is anybody using tailf at all? Google does not
>>> find much about people who are using this.
>>
>> tailf is a strange one. If there was an issue with tail(1) accessing
>> the files, then why not fix it? In any case it seems without inotify
>> that tailf(1) does access the file?
>>
>>   nanosleep({0, 250000000}, NULL)         = 0
>>   open("file", O_RDONLY)    = 3
>>   fstat(3, {st_mode=S_IFREG|0664, st_size=7048, ...}) = 0
>>   close(3)
>>
>> while tail -f does not:
>>
>>   nanosleep({0, 1000000000}, NULL)         = 0
>>   fstat(3, {st_mode=S_IFREG|0664, st_size=7048, ...}) = 0
> 
> Yes, I also checked this. The case undefined HAVE_INOTIFY_INIT is broken 
> since inotify support was added in 2007, fc7aeb09.
> 
> BTW I think there could be a minor improvement for coreutils tail for 
> the cases "file is empty" or "-n 0". Maybe we could skip opening the 
> file one time at the beginning. So that "tail -n0 -f logfile" would 
> really never access the file unless it grows.

I see what you mean, though I'm not convinced it's worth complicating GNU tail
for that edge case. Not updating atime is mainly a performance concern.
I.e. you want to avoid the continuous open() of the file
(though relatime alleviates a lot of that concern these days).

Are there valid cases where you really don't want to update atime
for logical reasons?  Maybe for forensics you might have logs that
only tail would access, and you want accurate atime for, but it does
seem like an extreme edge case.

thanks,
Pádraig.


  reply	other threads:[~2015-03-13 13:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13  9:00 tailf, really needed? Ruediger Meier
2015-03-13  9:32 ` Sami Kerola
2015-03-13 11:37 ` Pádraig Brady
2015-03-13 13:02   ` Ruediger Meier
2015-03-13 13:35     ` Pádraig Brady [this message]
2015-03-13 14:02       ` Ruediger Meier
2015-03-13 20:22     ` Ángel González
2015-03-14  4:50   ` Peter Cordes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5502E79E.20605@draigBrady.com \
    --to=p@draigbrady.com \
    --cc=sweet_f_a@gmx.de \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox