bug#21265: tail -f: inotify being used on non-regular files

[Pádraig Brady]

On 15/08/15 13:35, Stephane Chazelas wrote:
> Hello,
> 
> it seems on Linux, GNU tail -f uses inotify to check if data is
> available even for those types of files where inotify doesn't
> work.
> 
> For instance, when running:
> 
> tail -fn+1 /dev/tty
> 
> Then press 1<Return><Ctrl-D>2<Return><Ctrl-D>3<Return>4<Return>
> 
> $ tail -fn+1 /dev/tty
> 1
> 1
> ^D2
> 2
> ^D3
> 4
> 
> upon the first <Ctrl-D> tail installs an inotify watcher on
> /dev/tty and tries another read loop. But upon the second
> <Ctrl-D>, it waits on the inotify watch which will never return
> because inotify doesn't work on device files. So while 1 and 2
> are being displayed, 3 and 4 and anything afterwards are not.
> 
> That shouldn't be too big of a problem because it's unlikely one
> would use tail -f on a device and not many devices may return
> multiple eofs like tty devices do. AFAIK, pipes and sockets
> can't return more than one eof.
> 
> But I suppose if one ever wants to use tail -f on non-regular
> files, that would be for some that do exhibit a multiple-eof
> behaviour.
> 
> Work around for now is the undocumented ---disable-inotify
> option.

Yes, quite the edge case.
I notice both with and without inotify
there is a similar issue (for different reasons)
when multiple devices are specified:

  tail ---dis -f /dev/tty /dev/tty

I.E. we generally can't deal with this case in either case,
though it probably makes sense in any case to avoid inotify
for device nodes?

BTW, in the inotify case, theoretically the kernel should be returning
an error if the watch events are not supported?

The same argument applies that the kernel should return
and error when adding a watch on pseudo file systems like /proc?
To work around that, we'd have to get real kludgy and see
were the files on a "dummy" file system or something.
Though tail -f /proc files in either mode is not that useful,
so probably not worrying about that case.

thanks,
Pádraig.