Grep:/proc / sysrq-триггер: ошибка ввода / вывода

Я ищу файловую систему и использую grep. Я вижу, что все работает, пока не появится эта ошибка:

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

Я нашел информацию в разных местах сети, где другие столкнулись с той же проблемой, но нигде на самом деле не было ничего, что работало. Я попробовал 2>/dev / null, который подавил ошибку, но не "пропустил файл", который на самом деле я надеялся, что он будет делать. Вместо этого он просто останавливает процесс (который является процессом поиска/sed, использующим grep). Я думаю, есть способ указать файлы для исключения с помощью grep, но я надеюсь, что может быть более надежное и элегантное решение.

9
grep linux

2 ответов

похоже, что вы рекурсивно просматриваете всю иерархию файловой системы. Это не будет работать так, как ожидалось в большинстве систем.

на Linux по крайней мере /proc и /sys являются виртуальными файловыми системами - они не соответствуют фактическому файлу на диске. Специальные файлы в /dev также не являются фактическими файлами - они соответствуют некоторым устройствам в вашей системе, таким как жесткие диски, устройства ввода e.т. c. Изменение - и, иногда, даже чтение-файлов под любым из них каталоги никогда не должны происходить неконтролируемым образом, так как вы можете разбить ядро, разрушить ваши файловые системы и даже нанести постоянный ущерб вашему оборудованию.

если вы используете 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. Однако я рекомендую вам проверить его выход, прежде чем передавать его на любой из более поздних этапов конвейера.

EDIT:

вот несколько примеров ущерба, причиненного при доступе к определенным файлам неконтролируемым образом-обычно как root:

  • старых ядрах используется для аварии если /proc/kcore читать как root. Я считаю, что этого больше не происходит, но я столкнулся с этим с тех пор /proc/kcore был представлен в 2.4.ядра серии X и иногда всплывает снова, поэтому я не в настроении его тестировать...

  • чтение блочного устройства через его узел устройства в /dev/ может сильно замедлить любую другую операцию на этом устройстве, так как он обходит VFS и различные кэши. Представьте себе, например, чтение части 6TB RAID-5 напрямую, в то время как другие процессы пытаются использовать ее должным образом через установленную файловую систему. Используя -type f на find должно предотвратить это.

  • поскольку вы упомянули модификацию, вы можете легко заблокировать встроенное устройство, повредив его прошивку, которая доступна через /dev/mtd*. В некоторых случаях невозможно оправиться от такой коррупции без некоторых довольно крайних мер.

16

grep имеет параметр --exclude-dir=dir, который можно использовать, чтобы избежать /proc и / sys

недавно я использовал такую команду, где я знал только имя параметра, который я ожидал найти в каком-то конфигурационном файле, но не имел понятия о пути файла.

cd / && grep -rI --exclude-dir=proc --exclude-dir=sys pattern *
5