bug#26363: [PATCH] tail: 'tail -F dir/file' reverts to polling mode if 'dir' is removed

[Sebastian Kisela]

> Excellent. That looks like a fine fall back.
>
> Not having looked at the C code,
> have you considered if another dir/files are already setup with inotify
> watches,
> and if files are deleted but still open?
> Other comments below...
>

I changed the behaviour of tail to exit inotify mode if at least one of the
watched directories is deleted.

If I understand you correctly, there should not be problem with files that
are deleted while being open.
The files are tailed again in the polling mode, after the path leading to
them is recreated(tail -F uses following by name not by fd).

I also thought about entering inotify mode again after all watched
directories(and the files) are found by polling mode.
What I made so far, contained too many deleted and recreated watches due to
exiting inotify(deleting watches to all
inotify watch descriptors) mode immediately after at least one watched
directory is removed.

I have not found any discussion about such solution, therefore I am unsure
about the safety of the solution so far.


> Why this sleep?
>
> > +timeout 60 tail --follow=name --retry dir/file &>out  & pid=$!
> > +sleep 1
>
> We can't depend on absolute sleeps like this. See:
> http://www.pixelbeat.org/docs/coreutils-testing.html#backoff
> or the existing tail-2/ tests
>

I apologize, thanks for the tip.
See V2 patch attached with correct usage of sleep by

*retry_delay_ ().*

*Sebastian.*

inotify-dir-recreate-V2.patch
Description: Text Data