在最近的漏洞披露之后寻找系统parsing的服务，我从find命令中看到一个非常奇怪的行为。
root@localhost:/# find . -name "*systemd-resolved*" ./usr/share/man/man8/systemd-resolved.service.8.gz ./usr/share/man/man8/systemd-resolved.8.gz 该命令返回0或两行作为第一次运行的输出。 但是如果我第二次运行这个命令，我会得到：
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
这意味着第一次，“发现”实际上并没有find一切。 这也只发生一次。 下次运行该命令会显示正确的输出。 我在安装了Debian 8（jessie）的其他系统上检查了这个。 对于那些使用内核4.9+的人来说，这个确切的问题总是会发生，但是在内核3.16的系统上，这种情况不会发生
系统重启后，所有这一切都再次发生 但是每个系统的行为是一样的。 这意味着，如果对特定系统的testing返回（错误地）第一次运行的两行输出和第二次运行的正确输出，则在重新引导系统之后再次运行命令将打印两行。 所以系统在每次重启之后都会显示相同的行为（根据我的testing）。 档案详情如下：
-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
编辑：对于所有那些build议这个问题的人可能与这些特定的文件相关的这些特定的文件：“ 系统parsing ”就是例子。 这也发生在search其他关键字时。 这是另一个给第一次运行带来错误结果的例子：
root@localhost:/# find . -name "*apache*"
这里没有任何人可以用Debian 8上的最新内核从backport repository检查这个问题吗？
在Debian 8上安装的findutils的默认版本是4.4.2，这是jessie仓库上的最新版本。 我下载了findutils源代码的最新版本（4.6.0），并从源代码构build了二进制文件。 然后我做了相同的testing，“find”命令显示了第一次运行的正确输出。
然后，我从gnu档案下载了findutils 4.4.2版本的源代码并编译了它。 编译的find命令发生同样的问题。 所以这个问题在findutils 4.6.0中没有发生。
但是我仍然不知道为什么有些用户使用findutils 4.4.2（安装在Debian上的实用程序的默认版本）没有得到相同的结果，不知道为什么Debian仍然应该与这个旧版本的findutils一起发布可能还有其他Linux实用程序，并导致此问题的情况。 而最后一件事是什么奇怪的事情确切的技术原因仍然是未知的，这是不可取的。 因为我不确定在我的操作系统环境中是否有令人担忧的事情。