Question

I am searching a file system and utilising grep. I see that everything is working until this error appears:

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.

Answer 1

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 /proc and /sys are virtual filesystems – they do not correspond to an actual file on disk. The special files in /dev are 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.

Since you are using find to perform the search, you need to restrict the scope of its search:

• Use explicit negated -path options:

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

• Use the -prune option:

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

• Use the -xdev option to avoid descending to other filesystems completely:

  find / -maxdepth 2 -xdev -type f
  

You can use as many -path and/or -prune options 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.

EDIT:

Here are some examples of damage caused when accessing certain files in an uncontrolled manner – usually as root:

• Older kernels used to crash if /proc/kcore was read as root. I believe that this no longer happens, but I have encountered this since /proc/kcore was 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 f in find should 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.