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.
grep has an --exclude-dir=dir option that you can use to avoid /proc and /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 *
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With