在最近的漏洞披露之后搜索系统解析的服务,我看到了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
这意味着第一次,“发现”实际上并没有找到所有东西.这也只发生过一次.下次运行该命令会显示正确的输出.我在安装了Debian 8(jessie)的其他系统上检查过这个.对于那些使用Kernel 4.9的人来说,这个确切的问题总是会发生,但在内核3.16的系统上却不会发生.
系统重启后,所有这一切再次发生.但是每个系统的行为都是一样的.这意味着如果在特定系统上进行测试(错误地)返回第一次运行的两行输出并且为第二次运行返回正确的输出,则在重新启动系统后再次打印命令再打印2行.因此系统在每次重启后都会显示相同的行为(根据我的测试).
文件详细信息如下：
-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
编辑：对于所有建议问题的人可能与这些特定文件的特定案例有关：
“系统解决”就是一个例子.搜索其他关键字时也会发生这种情况这是另一个为第一次运行提供错误结果的示例：
root@localhost:/# find . -name "*apache*"
这里没有人能够使用backport存储库中的最新内核在Debian 8上检查此问题吗？
解决方法
Debian 8上安装的findutils的默认版本是4.4.2,这是jessie存储库的最新版本.
我下载了findutils源代码的最新版本(4.6.0)并从源代码构建了二进制文件.然后我做了相同的测试,“find”命令显示第一次运行的正确输出.
我下载了findutils源代码的最新版本(4.6.0)并从源代码构建了二进制文件.然后我做了相同的测试,“find”命令显示第一次运行的正确输出.
然后我从gnu archive下载了findutils版本4.4.2源代码并进行了编译.编译的find命令也发生了同样的问题.所以findutils 4.6.0不会出现这个问题.
但是我仍然不知道为什么有些用户使用findutils 4.4.2(Debian上安装的实用程序的默认版本)得不到相同的结果,并且不知道为什么Debian应该仍然与这个旧版本的findutils一起发布以及可能的其他Linux实用程序并导致这种有问题的情况.最后一件事是,奇怪发生的确切技术原因仍然是未知的,这是不可取的.因为我不确定我的操作系统环境中是否存在令人担忧的问题.
