在最近的漏洞披露之后寻找系统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实用程序,并导致此问题的情况。 而最后一件事是什么奇怪的事情确切的技术原因仍然是未知的,这是不可取的。 因为我不确定在我的操作系统环境中是否有令人担忧的事情。