even by default, it not longer waits for a second, but is more like 'real-time'

Tshepang Lekhonkhobe wrote:

I don't understand your comment in a bug report.  Being more
responsive seems like a good thing to me and good expected behavior.
Could you say a few words about why you are filing a bug report on
tail being more responsive?

See the /usr/share/doc/coreutils/News.gz file for a list of newsworthy
changes to tail.  In coreutils tail 7.5 tail aquired the ability to
use inotify.

  tail --follow now uses inotify when possible, to be more responsive
  to file changes and more efficient when monitoring many files.

Between versions 7.5 and 8.3 a period of instability resulted where
many bugs against tail's new behavior was reported.  (Newest on top.)

  tail -f (inotify-enabled) once again works with remote files.
  The use of inotify with remote files meant that any changes to those
  files that was not done from the local system would go unnoticed.
  [bug introduced in coreutils-7.5]

  tail -F (inotify-enabled) would abort when a tailed file is repeatedly
  renamed-aside and then recreated.
  [bug introduced in coreutils-7.5]

  tail -F (inotify-enabled) could fail to follow renamed files.
  E.g., given a "tail -F a b" process, running "mv a b" would
  make tail stop tracking additions to "b".
  [bug introduced in coreutils-7.5]

  tail without -f no longer access uninitialized memory
  [bug introduced in coreutils-7.6]

  tail -f (inotify-enabled) now avoids a race condition.
  Before, any data appended in the tiny interval between the initial
  read-to-EOF and the inotify watch initialization would be ignored
  initially (until more data was appended), or forever, if the file
  were first renamed or unlinked or never modified.
  [The race was introduced in coreutils-7.5]

  tail -F (inotify-enabled) now consistently tails a file that has been
  replaced via renaming.  That operation provokes either of two sequences
  of inotify events.  The less common sequence is now handled as well.
  [The bug came with the implementation change in coreutils-7.5]

  tail --follow --pid now avoids a race condition where data written
  just before the process dies might not have been output by tail.
  Also, tail no longer delays at all when the specified pid is not live.
  [The race was introduced in coreutils-7.5,
   and the unnecessary delay was present since textutils-1.22o]

  tail -f (inotify-enabled) now flushes any initial output before blocking.
  Before, this would print nothing and wait: stdbuf -o 4K tail -f /etc/passwd
  Note that this bug affects tail -f only when its standard output is buffered,
  which is relatively unusual.
  [bug introduced in coreutils-7.5]

  tail -f once again works with standard input.  inotify-enabled tail -f
  would fail when operating on a nameless stdin.  I.e., tail -f < /etc/passwd
  would say "tail: cannot watch `-': No such file or directory", yet the
  relatively baroque tail -f /dev/stdin < /etc/passwd would work. Now, the
  offending usage causes tail to revert to its conventional sleep-based
  (I.e., not inotify-based) implementation.
  [bug introduced in coreutils-7.5]

  tail -f now ignores "-" when stdin is a pipe or FIFO.
  tail-with-no-args now ignores -f unconditionally when stdin is a pipe or FIFO.
  Before, it would ignore -f only when no file argument was specified,
  and then only when POSIXLY_CORRECT was set.  Now, :|tail -f - terminates
  immediately.  Before, it would block indefinitely.

It seems to have settled down now and is back to functioning
acceptably for people again.

Bob

I can imagine that if someone is manually reviewing the output, they may
wish to have a certain interval to inspect new data before it is
scrolled by additional data.

Mike Stone

Michael Stone wrote:

In that case, use the deliberately undocumented ---disable-inotify
option that was introduced in coreutils-7.6.
With it, tail will sleep between iterations, as it did before.

I actually thought the --- in ---disable-inotify was a typo. First
time I see such.
Anyways, thanks for the tip, it works now.

That's my case actually, thanks.

At the least, tail should warn user that the option they asked for
(--sleep-interval) will be ignored.
At the most, tail should actually obey the option I asked for, and
that's what the bug report is about.