Grep: / proc / sysrq-trigger: ошибка ввода / вывода

Question

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

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

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

EDIT:

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

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

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

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

Answer 2

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

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

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