bugfindutils - Bugs: bug #51345, find shows different results...

 
 

bug #51345: find shows different results despite using same command

Submitter:  None
Submitted:  Fri 30 Jun 2017 07:45:45 AM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  CyrusSh Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.2
Fixed Release:  4.6.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 01 Sep 2019 02:03:01 PM UTC, comment #13: 

The problem is fixed in (or before) findutils 4.6.0.   Hence we can close this bug.   For what it is worth, the version of findutils in Debian Buster is slightly newer than that.

James Youngman <jay>
Group administrator
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.

cyrus <cyrussh>
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

Bernhard Voelker <berny>
Group administrator
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.

cyrus <cyrussh>
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.

James Youngman <jay>
Group administrator
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.

cyrus <cyrussh>
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.

cyrus <cyrussh>
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.

Dale Worley <worley>
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).

James Youngman <jay>
Group administrator
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"

James Youngman <jay>
Group administrator
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 '/'.

Bernhard Voelker <berny>
Group administrator
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.


cyrus <cyrussh>
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

Bernhard Voelker <berny>
Group administrator
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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by cyrussh (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-01 jay Assigned tojay None
        Fixed ReleaseNone 4.6.0
    2019-09-01 jay StatusNone Fixed
        Assigned toNone jay
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code