Thu 06 Jul 2017 01:25:40 PM UTC, comment #12:
finutils4.6.0/find/oldfind also worked correctly for the test case I provided.
|
Thu 06 Jul 2017 01:18:16 PM UTC, comment #11:
okay, that's good news - so the fix the Debian project needs
is most probably somewhere in these 265 commits:
$ git log --oneline FINDUTILS_4_4_2-1..v4.6.0 -- find lib | wc -l
265
To narrow it down even more, would you please check again with
both the "$BUILD/find/find" and "$BUILD/find/oldfind" binary?
(The latter may not be built anymore for 4.6 per default, but
you can build it manually in that directory with "make oldfind".)
Thanks & have a nice day,
Berny
|
Thu 06 Jul 2017 12:43:29 PM UTC, comment #10:
I download latest version (4.6.0) of findutils source code and built the binaries from source. Then I did same tests and "find" command showed correct output for the first run.
Then I downloaded findutils version 4.4.2 source code from gnu archive and compiled it. Performed same tests and it showed same wrong results for the first run.
I still don't know what the root of this strange problem is.
|
Thu 06 Jul 2017 11:07:04 AM UTC, comment #9:
If you are only willing to use the binaries provided in your Linux distribution, then you should ask for support and help from that Linux distribution.
The GNU project supports the "upstream" release - we release it as source code, not binaries - which you're very welcome to use, modify, and ask for help with. But we don't (directly) support the binaries shipped by Linux distributions.
|
Thu 06 Jul 2017 08:55:54 AM UTC, comment #8:
I also asked about the same problem here: https://serverfault.com/questions/858747/linux-find-command-is-misbehaving
Please take a look so I don't have to repeat all my comments here as well.
|
Thu 06 Jul 2017 08:38:53 AM UTC, comment #7:
noleaf option doesn't make any difference. And yes as I said I repeat again all those files exist and are accessible from the beginning. I expected you to test this problem on a Debian with latest kernel to see whether it happens or not, sounds you haven't done this so far.
About checking the last version and building from source I should say this is not a solution as the problem is occurring with the default version of findutils which is ported with Debian releases. If the problem is this version you should ask Debian developers to use the newer version. But personally I am more curios about the actual technical root of this issue. If that's the kernel it might be something serious.
I ran the command using busybox and the problem did not happen. So the version of "find" compiled into busybox binary doesn't seem to have this problem.
|
Thu 06 Jul 2017 02:01:16 AM UTC, comment #6:
I don't want to sound like a crank, but are you verifying that the files in question actually exist before you run find?
I mean, before you run find the first time, are you doing "ls /lib/systemd" to verify that the directory is accessible when find is run? All this talk about "I reboot and ..." leaves me suspicious that rebooting is part of the problem.
Best would be to assemble a script of the steps that demonstrate the error, with the shell prompt modified to show the time. Then run it with your shell to have a clearly-repeatable error case.
|
Wed 05 Jul 2017 08:03:21 PM UTC, comment #5:
Oh, also try to compare the behaviour of "oldfind" which is built at the same time as "find", when you compile findutils from source (though your distribution likely does not ship it).
|
Wed 05 Jul 2017 08:01:53 PM UTC, comment #4:
Try again, passing also the option -noleaf to find.
If it works with -noleaf but not without it, one of the directories in the tree you searched has an incorrect[*] link count (i.e. st_nlink > 2 but not equal to 2 + the number of immediate child directories).
[*] by incorrect I really mean "not providing the usual Unix filesystem semantics"
|
Tue 04 Jul 2017 11:27:45 PM UTC, comment #3:
Okay, so this happens after a fresh reboot.
Thanks for the strace logs; but please compress them the next time because it was 12M+37M to download.
If I got it right, then the last directory processed in the 1st run was
/proc/sys/kernel/debug/tracing/events/raw_syscalls/sys_exit
and then ended normally while the second run continued with
/proc/sys/kernel/debug/tracing/instances
Interestingly, the 1st run didn't find any match:
there was no write() system call at all. Really strange.
Back to my other question: did you try with a newer version of find,
either the latest release 4.6 or even a version built from the Git repository?
I mean, 4.4.2 is about eight years old, and a lot has changed since then.
I didn't find an obvious bug fix for this in the NEWS by a very brief look,
but I don't want to spend much time riding a dead horse.
Thanks & have a nice day,
Berny
P.S. It is probably a good idea to skip file system types like /proc and /sys,
because they may contain loops and usually don't contain the information one
is searching for, so I usually use the -xdev option when searching from the
root directory '/'.
|
Tue 04 Jul 2017 03:44:32 PM UTC, comment #2:
I thought the explanations should be enough. To clarify the problem I re-explain what happens:
I turn on my Linux machine which has Debian 8 x64 (unstable- kernel 4.9) installed on it. I run the command
> #find . -name "systemd-resolved"
and get this output:
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
I run the SAME command for the second time and get this output:
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service
File system is ext4 and ALL the files exist there and are accessible before running the commands. Now after rebooting this system the same thing happens exactly like what I said.
I turn on another system with Debian x64 kernel 4.9 which is installed as a virtual machine.
Running the same command I get another wrong result. But this time instead of two lines, the output is empty.
(Download strace log of first run: https://ufile.io/yjluf)
I run the command for the second time and get correct result:
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service
(Download strace log of second log: https://ufile.io/zweyz)
This all happens after rebooting the second machine too: Wrong output for the first run.
|
Mon 03 Jul 2017 08:40:47 PM UTC, comment #1:
This is strange, indeed. Furthermore, it would be good to have more information
to reproduce the issue.
To narrow things down, I suggest that you log the system calls into logfiles
using "strace -v -o logfile find ...".
Next, it is unclear to me what you mean by "first time" vs. "next times":
when mounting the filesystem for the first time after creation, after each reboot,
after mounting the filesystem on a running system, first time after ...?
Furthermore, what filesystem type are you using? Don't other Debian users have
the same issue? What's different there?
To be honest, I don't think this is a find(1) issue, as all subsequent calls
seem to be stable. So this would point more to the direction of the kernel
or filesystem.
Finally, could you reproduce with latest findutils-4.6? And which kind of find(1)
do you run: oldfind or the new FTS-based version?
Have a nice day,
Berny
|
Fri 30 Jun 2017 07:45:45 AM UTC, original submission:
During working on terminal I came to see a very strange behavior from find command. This is the command I run along with its output:
root@localhost:/# find . -name "systemd-resolved"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
The command returns 0 or two results like above. But if I run the command the second time I get:
root@localhost:/# find . -name "systemd-resolved"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service
This means the first time, "find" does not actually find everything. Also this only happens one time. Running the command next times shows correct output. I checked this on some other systems with Debian OS installed. On those with Kernel 4.9+ this exact problem always occurs but on systems with kernel 3.16 it doesn't happen.
|