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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21265 in the body.
You can then email your comments to 21265 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: tail -f: inotify being used on non-regular files
Date: Sat, 15 Aug 2015 13:35:48 +0100

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.

-- 
Stephane

Message #8 received at 21265 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Stephane Chazelas <stephane.chazelas <at> gmail.com>, 
 21265 <at> debbugs.gnu.org
Subject: Re: bug#21265: tail -f: inotify being used on non-regular files
Date: Wed, 26 Aug 2015 03:13:59 +0100

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.

Message #11 received at 21265 <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 21265 <at> debbugs.gnu.org
Subject: Re: bug#21265: tail -f: inotify being used on non-regular files
Date: Wed, 26 Aug 2015 12:19:59 +0100

2015-08-26 03:13:59 +0100, Pádraig Brady:
[...]
> 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.
[...]

All very good points.

Many files in /proc, /sys... can only be read reliably in one read()
operation anyway, and doing tail -f on them would give you
garbage even if it worked.

I guess the best approach would be to only use inotify for
regular files, address blocking files (pipe, devices...) when
several files are being watched with poll() and/or non-blocking
IO, or alarm()/timers or threads, and document the other issues.

Or not do anything and just document those limitations as they
are mostly edge cases.

-- 
Stephane

Message #14 received at 21265 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 21265 <at> debbugs.gnu.org
Subject: Re: bug#21265: tail -f: inotify being used on non-regular files
Date: Wed, 24 Oct 2018 14:57:24 -0600

tags 21265 wontfix
close 21265
stop

(triaging old bugs)

On 26/08/15 05:19 AM, Stephane Chazelas wrote:
> 2015-08-26 03:13:59 +0100, Pádraig Brady:
> [...]
>>
>> 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.
> [...]
> 
> All very good points.
> 
> Many files in /proc, /sys... can only be read reliably in one read()
> operation anyway, and doing tail -f on them would give you
> garbage even if it worked.

Given the above, and no further comments in 3 years,
I'm closing this bug.

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.