bug#47940: tests/tail-2/inotify-dir-recreate.sh FAILs for remote filesystems that passes is_local_dir_

Hi Carl,

> I am debugging a reproducible test failure in
> tests/tail-2/inotify-dir-recreate.sh for coreutils 8.32.
>=20
> Logs: https://gist.githubusercontent.com/dongcarl/d24bfe853cc5bd9402bba82=
c36513c07/raw/19b9a15c4b12edf601dd1504cdf4ec0ee0d9344c/inotify-dir-recreate=
.log
>=20
> Looking at the non-=E2=80=98+=E2=80=99 lines, and the final compare diff,=
 we can see
> that the =E2=80=9Cout=E2=80=9D file only contained the string =E2=80=9Cin=
otify=E2=80=9D and nothing
> else.
>=20
> From my understanding, it has to do with the fact that I=E2=80=99m running
> this test in a directory which is on overlayfs, which is considered
> =E2=80=9Cremote=E2=80=9D by tail (see `fremote(int, const char*)`). The f=
ilesystem
> being =E2=80=9Cremote=E2=80=9D should ordinarily trigger one of the 2 SKI=
P checks in
> this test, however, neither check triggered a SKIP.
>=20
> Check 1: is_local_dir_
>=20
> At the top of inotify-dir-recreate.sh, we invoke is_local_dir_ to make
> sure that we=E2=80=99re in a =E2=80=9Clocal=E2=80=9D filesystem. However,=
 is_local_dir_
> invokes `df --local`, which does not use =E2=80=9C=E2=80=8Cfremote=E2=80=
=9D to determine
> filesystem locality, but rather =E2=80=9Cread_file_system_list=E2=80=9D f=
rom gnulib.
> The =E2=80=9Cme_remote=E2=80=9D field of the returned =E2=80=9Cmount_entr=
y" struct is then
> used to filter out entries which are non-local. However, in the case
> of overlayfs, the =E2=80=9Cme_remote=E2=80=9D field will be false, and it=
 will be
> considered =E2=80=9Clocal=E2=80=9D by `df --local`
>
> TL;DR: is_local_dir_ =3D =E2=80=9Cis possibly local=E2=80=9D, but we real=
ly want to
> check if =E2=80=9Cis possibly remote=E2=80=9D
>
> Check 2: Grepping for 'inotify (resources exhausted|cannot be used)'
>=20
> Here, we expect that if inotify cannot be used, tail will print an
> indication to stderr and we can skip this test. However, this message
> is not printed when inotify is disabled in the fast-failing codepath:
> https://github.com/coreutils/coreutils/blob/v8.32/src/tail.c#L2490-L2512
>=20
> I think the easiest fix might be to have tail output =E2=80=98inotify can=
not
> be used=E2=80=99 to stderr in the fast-failing disable case:
> https://github.com/coreutils/coreutils/blob/v8.32/src/tail.c#L2490-L2496.
>=20
> It seems like this bug has been encountered by others as well:
> 1. https://dnsglk.github.io/lfs/2018/06/28/lfs-coreutils-test-issue.html#=
inotify-dir-recreate
> 2. https://github.com/containers/podman/issues/5493#issuecomment-598851397

Apologies for the very late response. P=C3=A1draig mostly fixed this issue
last year, by checking for inotify support and skipping those tests if
'tail' didn't use it [1].

I did some testing in a container using overlayfs recently and fixed a
spot missed in that commit [2][3]. I didn't see this report until after,
sorry about that.

Going to close it, but let us know if you run into that issue again.

Collin

[1] https://github.com/coreutils/coreutils/commit/eebe2abbb6a582550d88d0ee7=
4be4d4f0bf253bd
[2] https://github.com/coreutils/coreutils/commit/54f88c7f2ed565cbd2b73798f=
8399bc139dc75cd
[2] https://github.com/coreutils/coreutils/commit/ab6b01f40fbb5a755daa3352a=
0f14ca71b7a1103