Hi Carl, > I am debugging a reproducible test failure in > tests/tail-2/inotify-dir-recreate.sh for coreutils 8.32. > > Logs: > https://gist.githubusercontent.com/dongcarl/d24bfe853cc5bd9402bba82c36513c07/raw/19b9a15c4b12edf601dd1504cdf4ec0ee0d9344c/inotify-dir-recreate.log > > Looking at the non-‘+’ lines, and the final compare diff, we can see > that the “out” file only contained the string “inotify” and nothing > else. > > From my understanding, it has to do with the fact that I’m running > this test in a directory which is on overlayfs, which is considered > “remote” by tail (see `fremote(int, const char*)`). The filesystem > being “remote” should ordinarily trigger one of the 2 SKIP checks in > this test, however, neither check triggered a SKIP. > > Check 1: is_local_dir_ > > At the top of inotify-dir-recreate.sh, we invoke is_local_dir_ to make > sure that we’re in a “local” filesystem. However, is_local_dir_ > invokes `df --local`, which does not use “fremote” to determine > filesystem locality, but rather “read_file_system_list” from gnulib. > The “me_remote” field of the returned “mount_entry" struct is then > used to filter out entries which are non-local. However, in the case > of overlayfs, the “me_remote” field will be false, and it will be > considered “local” by `df --local` > > TL;DR: is_local_dir_ = “is possibly local”, but we really want to > check if “is possibly remote” > > Check 2: Grepping for 'inotify (resources exhausted|cannot be used)' > > 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 > > I think the easiest fix might be to have tail output ‘inotify cannot > be used’ to stderr in the fast-failing disable case: > https://github.com/coreutils/coreutils/blob/v8.32/src/tail.c#L2490-L2496. > > 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ádraig 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/eebe2abbb6a582550d88d0ee74be4d4f0bf253bd [2] https://github.com/coreutils/coreutils/commit/54f88c7f2ed565cbd2b73798f8399bc139dc75cd [2] https://github.com/coreutils/coreutils/commit/ab6b01f40fbb5a755daa3352a0f14ca71b7a1103
