问题:Grep: /proc/sysrq-trigger: 输入/输出错误

我正在搜索文件系统并使用 grep。我看到一切正常,直到出现此错误:

Grep: /proc/sysrq-trigger: Input/output error

我在网上的各个地方都找到了其他人遇到同样问题的信息,但没有任何地方真正有效。我尝试了 2>/dev/null 来抑制错误但没有“跳过文件”,这确实是我希望它会做的。相反,它只是停止进程(这是一个使用 grep 的 find/sed 进程)。我认为有一种方法可以使用 grep 指定要排除的文件,但我希望可能有一个更强大和优雅的解决方案。

解答

听起来好像您正在递归搜索整个文件系统层次结构。在大多数系统上,这不会像预期的那样工作。

在 Linux 上,至少/proc和/sys是虚拟文件系统——它们不对应于磁盘上的实际文件。/dev中的特殊文件也不是实际文件——它们对应于您系统上的一些设备,例如硬盘、输入设备等。修改(有时甚至读取)这些目录下的文件绝不应以不受控制的方式发生,因为您可能会导致内核崩溃,破坏文件系统,甚至对硬件造成永久性损坏。

由于您使用find执行搜索,因此您需要限制其搜索范围:

• 使用显式否定的-path选项:

查找 / -maxdepth 2 -type f ! -path '/proc/*' ! -path '/sys/*'

• 使用-prune选项:

zoz100027`

find / -maxdepth 2 -path '/proc' -prune -o -path '/sys' -prune -o -type f -print

* 使用`-xdev`选项来完全避免下降到其他文件系统:

查找 / -maxdepth 2 -xdev -type f

您可以根据需要使用尽可能多的`-path`和/或`-prune`选项来微调`find`的输出。不过,我建议您检查其输出,然后再将其传递到管道中的任何后期阶段。

**编辑:**

以下是一些以不受控制的方式访问某些文件时造成的损坏的示例 - 通常为`root`:

* 如果`/proc/kcore`被读取为`root`,则旧内核[会导致](https://bugzilla.kernel.org/show_bug.cgi?id=13850)崩溃。我相信这不再发生,但是自从`/proc/kcore`在 2.4.x 内核系列中引入后,我就遇到了这种情况,并且[偶尔会再次弹出](http://osdir.com/ml/xen-development/2011-02/msg01157.html),所以我没有心情实际测试它...

* 通过`/dev/`中的设备节点读取块设备会严重减慢该设备上的任何其他操作,因为它绕过了 VFS 和各种缓存。例如,想象一下,直接读取 6TB RAID-5 分区,而其他进程试图通过已安装的文件系统正确使用它。在`find`中使用`-type f`应该可以防止这种情况发生。

* 既然你提到了修改,你可以很容易地通过破坏它的固件来破坏一个嵌入式设备,可以通过`/dev/mtd*`访问它。在某些情况下,如果不采取一些非常极端的措施,就不可能从这种腐败中恢复过来。