GNU bug report logs -
#74653
tail --follow=name doesn't exit when using inotify and the file is moved
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 74653 in the body.
You can then email your comments to 74653 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#74653
; Package
coreutils
.
(Mon, 02 Dec 2024 16:20:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Göran Uddeborg <goeran <at> uddeborg.se>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Mon, 02 Dec 2024 16:20:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When using "tail --follow=name", but without "--retry", on a file
supporting inotify, the command doesn't finish if the file is moved to
a new name.
Repeat this way on a local filesystem:
echo apa > apa
tail --follow=name apa &
mv apa bepa
"tail" will print an error message saying "No such file or directory",
but it will continue running. I would expect a following message "no
files remaining" and "tail" to exit.
If the file system doesn't support inotify, if "apa" is on NFS for
example, "tail" exits as expected.
If the file is removed rather than moved ("rm apa") "tail" also exits
as expected.
This is tested on Fedora 41 using
coreutils-9.5-11.fc41.x86_64
kernel-6.11.6-300.fc41.x86_64
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#74653
; Package
coreutils
.
(Wed, 04 Dec 2024 11:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74653 <at> debbugs.gnu.org (full text, mbox):
On 02/12/2024 16:19, Göran Uddeborg wrote:
> When using "tail --follow=name", but without "--retry", on a file
> supporting inotify, the command doesn't finish if the file is moved to
> a new name.
>
> Repeat this way on a local filesystem:
>
> echo apa > apa
> tail --follow=name apa &
> mv apa bepa
>
> "tail" will print an error message saying "No such file or directory",
> but it will continue running. I would expect a following message "no
> files remaining" and "tail" to exit.
>
> If the file system doesn't support inotify, if "apa" is on NFS for
> example, "tail" exits as expected.
>
> If the file is removed rather than moved ("rm apa") "tail" also exits
> as expected.
>
> This is tested on Fedora 41 using
>
> coreutils-9.5-11.fc41.x86_64
> kernel-6.11.6-300.fc41.x86_64
Yes that is a bug.
The info docs state this:
"In that [renamed file] case, use ‘--follow=name’ to track the named file,
perhaps by reopening it periodically to see if it has been removed
and recreated by some other program. Note that the inotify-based
implementation handles this case without the need for any periodic reopening."
But that description only alludes to the implementation,
and not any functional difference I would say.
I.e. inotify should not imply --retry.
Interestingly if you `rm depa` before recreating "apa" in the example above,
then tail does exit. Also tail will exit immediately if "apa" is not present
at startup. Also tail will exit if you move "apa" to a different directory.
All of those existing behaviors gives us latitude to adjust this behavior I think,
so that tail does in fact exit for the case above with inotify.
BTW one can test the non-inotify behavior on any file system
with the undocumented ---disable-inotify option.
thanks,
Pádraig
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Thu, 05 Dec 2024 12:57:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Göran Uddeborg <goeran <at> uddeborg.se>
:
bug acknowledged by developer.
(Thu, 05 Dec 2024 12:57:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 74653-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/12/2024 11:55, Pádraig Brady wrote:
> On 02/12/2024 16:19, Göran Uddeborg wrote:
>> When using "tail --follow=name", but without "--retry", on a file
>> supporting inotify, the command doesn't finish if the file is moved to
>> a new name.
>>
>> Repeat this way on a local filesystem:
>>
>> echo apa > apa
>> tail --follow=name apa &
>> mv apa bepa
>>
>> "tail" will print an error message saying "No such file or directory",
>> but it will continue running. I would expect a following message "no
>> files remaining" and "tail" to exit.
>>
>> If the file system doesn't support inotify, if "apa" is on NFS for
>> example, "tail" exits as expected.
>>
>> If the file is removed rather than moved ("rm apa") "tail" also exits
>> as expected.
>>
>> This is tested on Fedora 41 using
>>
>> coreutils-9.5-11.fc41.x86_64
>> kernel-6.11.6-300.fc41.x86_64
>
> Yes that is a bug.
> The info docs state this:
>
> "In that [renamed file] case, use ‘--follow=name’ to track the named file,
> perhaps by reopening it periodically to see if it has been removed
> and recreated by some other program. Note that the inotify-based
> implementation handles this case without the need for any periodic reopening."
>
> But that description only alludes to the implementation,
> and not any functional difference I would say.
> I.e. inotify should not imply --retry.
>
> Interestingly if you `rm depa` before recreating "apa" in the example above,
> then tail does exit. Also tail will exit immediately if "apa" is not present
> at startup. Also tail will exit if you move "apa" to a different directory.
> All of those existing behaviors gives us latitude to adjust this behavior I think,
> so that tail does in fact exit for the case above with inotify.
>
> BTW one can test the non-inotify behavior on any file system
> with the undocumented ---disable-inotify option.
I'll push the attached later to fix this.
Marking this as done.
thanks,
Pádraig
[tail-unfollow-renames.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#74653
; Package
coreutils
.
(Sat, 07 Dec 2024 18:56:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 74653 <at> debbugs.gnu.org (full text, mbox):
Thank you for a quick follow up and prompt fix of this issue!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 05 Jan 2025 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 165 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.