Linux Grep：/proc/sysrq-trigger：输入/输出错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9452104/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Grep: /proc/sysrq-trigger: Input/output error
提问by user1166981
I am searching a file system and utilising grep. I see that everything is working until this error appears:
我正在搜索文件系统并使用 grep。我看到一切正常，直到出现此错误：
Grep: /proc/sysrq-trigger: Input/output error
I have found information in various places on the net where others have come accross the same problem, but nowhere really was there anything that worked. I tried 2>/dev/null which supressed the error but didn't 'skip the file' which is really what I hoped it would do. Instead it just stops the process (which is a find/sed process utilising grep). I think there is a way to specify files for exclusion using grep, but I am hoping that there may be a more robust and elegant solution.
我在网上的不同地方找到了其他人遇到同样问题的信息，但没有任何地方真正有效。我尝试了 2>/dev/null ，它抑制了错误，但没有“跳过文件”，这正是我希望它能做的。相反，它只是停止进程（这是一个使用 grep 的 find/sed 进程）。我认为有一种方法可以使用 grep 指定要排除的文件，但我希望可能有更健壮和优雅的解决方案。
采纳答案by thkala
It sounds as if you are recursively searching your entire filesystem hierarchy. That won't work as expected on most systems.
听起来好像您正在递归搜索整个文件系统层次结构。这在大多数系统上不会按预期工作。
On Linux at least /procand /sysare virtual filesystems - they do not correspond to an actual file on disk. The special files in /devare also not actual files - they correspond to some of the devices on your system, such as hard disks, input devices e.t.c. Modifying - and, occasionally, even reading - files under any of these directories should never happen in an uncontrolled manner, since you can crash the kernel, ruin your filesystems and even cause permanent damage to your hardware.
至少在 Linux 上/proc并且/sys是虚拟文件系统 - 它们不对应于磁盘上的实际文件。中的特殊文件/dev也不是实际文件 - 它们对应于系统上的某些设备，例如硬盘、输入设备等方式，因为您可能会崩溃内核，破坏您的文件系统，甚至对您的硬件造成永久性损坏。
Since you are using findto perform the search, you need to restrict the scope of its search:
由于您是find用来执行搜索的，因此您需要限制其搜索范围：
Use explicit negated
-pathoptions:find / -maxdepth 2 -type f ! -path '/proc/*' ! -path '/sys/*'Use the
-pruneoption:find / -maxdepth 2 -path '/proc' -prune -o -path '/sys' -prune -o -type f -printUse the
-xdevoption to avoid descending to other filesystems completely:find / -maxdepth 2 -xdev -type f
使用显式否定
-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
You can use as many -pathand/or -pruneoptions as you need to fine-tune the output of find. I recommend, though, that you inspect its output before passing it to any of the later stages in the pipeline.
您可以根据需要使用尽可能多的-path和/或-prune选项来微调find. 不过，我建议您在将其传递给管道中的任何后期阶段之前检查其输出。
EDIT:
编辑：
Here are some examples of damage caused when accessing certain files in an uncontrolled manner - usually as root:
以下是一些以不受控制的方式访问某些文件时造成的损坏示例 - 通常为root：
Older kernels used to crashif
/proc/kcorewas read asroot. I believe that this no longer happens, but I have encountered this since/proc/kcorewas introduced in the 2.4.x kernel series and it occasionally pops up again, so I am in no mood to actually test it...Reading a block device via its device node in
/dev/can severely slow down any other operation on that device, since it bypasses the VFS and various caches. Imagine, for example, reading a 6TB RAID-5 partion directly, while other processes attempt to use it properly via the installed filesystem. Using-type finfindshould prevent this from happening.Since you mentioned modification, you could easily brick an embedded device by corrupting its firmware, which is accessible via
/dev/mtd*. In some cases its impossible to recover from such corruption without some pretty extreme measures.
老版本的内核使用的崩溃，如果
/proc/kcore读成root。我相信这种情况不会再发生了，但是自从/proc/kcore在 2.4.x 内核系列中引入以来我就遇到过这种情况，并且它偶尔会再次弹出，所以我没有心情实际测试它......通过其设备节点读取块设备
/dev/会严重减慢该设备上的任何其他操作，因为它绕过了 VFS 和各种缓存。例如，想象一下，直接读取 6TB RAID-5 分区，而其他进程尝试通过安装的文件系统正确使用它。使用-type finfind应该可以防止这种情况发生。由于您提到了修改，因此您可以通过破坏其固件（可通过
/dev/mtd*. 在某些情况下，如果不采取一些非常极端的措施，就不可能从这种腐败中恢复过来。
回答by peepsalot
grep has an --exclude-dir=dir option that you can use to avoid /proc and /sys
grep 有一个 --exclude-dir=dir 选项，您可以使用它来避免 /proc 和 /sys
I used a command like this recently where I only knew the name of a parameter that I expected to be in some config file, but had no clue about the file's path.
我最近使用了一个这样的命令，我只知道我希望在某个配置文件中的参数的名称，但不知道文件的路径。
cd / && grep -rI --exclude-dir=proc --exclude-dir=sys pattern *
