ファイルシステムを検索してgrepを利用しています。このエラーが表示されるまで、すべてが機能していることがわかります。
Grep: /proc/sysrq-trigger: Input/output error
他の人が同じ問題に遭遇したネット上のさまざまな場所で情報を見つけましたが、実際に機能するものはどこにもありませんでした。エラーを抑制した2> / dev / nullを試しましたが、「ファイルをスキップ」しませんでした。代わりに、プロセス（grepを使用したfind / sedプロセス）を停止するだけです。grepを使用して除外するファイルを指定する方法はあると思いますが、より堅牢でエレガントなソリューションが存在することを期待しています。
ファイルシステム階層全体を再帰的に検索しているように聞こえます。これは、ほとんどのシステムで期待どおりに機能しません。
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。ただし、パイプラインの後のステージに渡す前に、その出力を検査することをお勧めします。
編集：
以下は、制御されていない方法で特定のファイルにアクセスしたときに引き起こされる損傷の例ですroot。
古いカーネルがクラッシュするために使用場合/proc/kcoreとして読み取りましたroot。私はこれはもう起こらないと信じていますが、/proc/kcore2.4.xカーネルシリーズで導入されてからこの問題に遭遇し、時々再びポップアップするので、実際にテストする気はありません...
デバイスノードを介してブロックデバイスを読み取る/dev/と、VFSとさまざまなキャッシュをバイパスするため、そのデバイスの他の操作が大幅に遅くなる可能性があります。たとえば、他のプロセスがインストールされたファイルシステムを介して6TBのRAID-5パーティションを直接読み取ることを想像してみてください。-type fin findを使用すると、これが発生するのを防ぐことができます。
変更について説明したので、を介してアクセスできるファームウェアを破壊することで、組み込みデバイスを簡単にブリックできます/dev/mtd*。場合によっては、かなり極端な対策を講じないと、このような破損から回復することが不可能です。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加