Searching for system-resolved service following the recent vulnerability disclosure, I came to see a very strange behavior from find command.

 root@localhost:/# find . -name "*systemd-resolved*"

The command returns 0 or two lines as output for the first run. But if I run the command the second time I get:

root@localhost:/# find . -name "*systemd-resolved*"

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 8 (jessie) installed. On those with Kernel 4.9+ this exact problem always occurs but on systems with kernel 3.16 it doesn't happen.
After system reboot all this happen again. But the behavior is the same for each individual system. That means that if testing on a specific system returns (wrongly) two lines of output for first run and correct output for second run, then first run of the command after rebooting the system again prints 2 lines. So the systems show same behavior after each reboot (according to my tests). Files details are as follows:

-rw-r--r-- 1 root root  ./usr/share/man/man8/systemd-resolved.service.8.gz
lrwxrwxrwx 1 root root  ./usr/share/man/man8/systemd-resolved.8.gz -> systemd-resolved.service.8.gz
-rwxr-xr-x 1 root root  ./lib/systemd/systemd-resolved
drwxr-xr-x 2 root root  ./lib/systemd/system/systemd-resolved.service.d
-rw-r--r-- 1 root root  ./lib/systemd/system/systemd-resolved.service

EDIT: To all those who suggest the problem maybe related to this specific case for these specific files: "system-resolved" is just as example. This happens when searching other keywords too. This is another example which gives wrong results for the first run:

root@localhost:/# find . -name "*apache*"

Not anybody here is able to check this problem on a Debian 8 with latest kernel from backport repository?

  • 2
    Can you try comparing traces of the two calls, for example using strace? Which OS did you observe the faulty behaviour on? What do you mean by "returns 0 or two results like above"? Zero or two lines of output, or exit code 0 + two lines? Does it happen again after starting a new shell or rebooting? It might be relevant that the first call only returns files, while the second returns files and directories. – l0b0 Jun 30 '17 at 13:38
  • 1
    @l0b0 As I said it happens on Debian with Kernel 4.9 in multiple systems. I did not check other distros. 0 or 2 means zero or two lines of output. It happens after every reboot. Your last statement does not apply here. It attempts to return everything. Both directories and files. – user2808671 Jun 30 '17 at 13:46
  • 1
    @l0b0 Well I'm not sure what you're looking for, but as you can see I have mentioned the command so that one be able to reproduce the issue. That command must return all paths containing "systemd-resolved" but it won't. There are total five paths satisfying this condition but the "find" program only returns two of them or one or zero. What matters here is that the tool is giving wrong output and misses some correct paths. And as I mentioned I checked this on other systems with Debian, those with kernel 4.9 have this problem. This might be something serious beyond user space. – user2808671 Jun 30 '17 at 14:25
  • 2
    @MarkWagner No. I filled a bug report to both gnu findutils and Debian backports mailing list. This seems very serious to me as the source of this problem may affect many other things though I don't know whether you guys agree with me. Anyways "find" is a very popular tool and its output must be reliable. – user2808671 Jun 30 '17 at 18:44
  • 2
    How is /lib/systemd mounted? What kind of filesystem is it? If it's a separate mount point, what time was it mounted? – Andrew Henle Jul 1 '17 at 12:21

The default version of findutils which is installed on Debian 8 is 4.4.2 and this is the newest version on jessie repositories. 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. The same problem happened for the compiled find command. So this problem is not happening with findutils 4.6.0.

But I still don't know why some users don't get same results using findutils 4.4.2 (the default version of the utility installed on Debian), and don't know why Debian should still be released with this old version of findutils and possibly other Linux utilities and cause this problematic situation. And the last thing is that the exact technical reason of what strangely happened is still unknown which is not desirable. Because I'm not sure whether there's something worrisome in my OS environment.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.