linux - grep:/proc/sysrq-trigger: 输入/输出错误

Question

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

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

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

Answer 1

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

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

由于您使用的是 find要执行搜索，您需要限制其搜索范围:

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

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

• 使用 -prune 选项:

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

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

  find / -maxdepth 2 -xdev -type f
  

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

编辑:

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

• 旧内核 used to crash如果 /proc/kcore 被读取为 root。我相信这不再发生了，但是自从 /proc/kcore 在 2.4.x 内核系列中引入以来我就遇到过这种情况，它 occasionally pops up again ，所以我没有心情实际测试它......

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

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