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

 
 

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

Submitted by:  None
Submitted on:  Fri 30 Jun 2017 07:45:45 AM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: None
Privacy: PublicAssigned to: None
Originator Name: CyrusShOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.4.2
Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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>
Project Member
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>
Project 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>
Project 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>
Project 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>
Project Member
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>
Project Member
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1