/ dev / nullファイルが通常のファイルになりました


19

本番サーバーで/dev/nullは、突然通常のファイルになり、このためsshdサービスが停止し、サーバーにログインできなくなりました。また、キャラクターデバイスファイルに戻るように設定するために以下の手順を試みました。

rm -rf /dev/null
mknod /dev/null c 1 3

実行するとすぐに、rmコマンド/dev/nullmknod実行前に通常のファイルとして再作成されます。これがどのように発生し、どのコンポーネントがこのファイルを作成しているかはわかりません。したがって、この問題を解決するまで/dev/null、キャラクターデバイスファイルとして作成することはできません。


サーバーで使用しているOSとリリースは何ですか?udevがファイルを作成している可能性があります。
ptman

Centos 5.2と、udevがこのファイルを作成する方法を詳しく説明してください。
user197719

man fuser、ファイルにアクセスするプロセスを見つけてそれを強制終了できます。そのようなファイルに属性を付けることができます-man chattr。
ジリブ

便利なcentosマシンはありませんが、ubuntu 12.04には/lib/udev/rules.d/50-udev-default.rules作成のルールがあります/dev/null
-ptman

3
lsof /dev/nullあなたの友だちです。
アンドリューB

回答:


29

/ dev / nullを削除(rm)すると、実行中の「> / dev / null」または同等のプログラム/スクリプトがあれば、その名前の新しい(通常の)ファイルが再作成されます。そして、それらはいつでも生成できます(また、一部は継続的に書き込みを行うこともあります)

それらを倒すには:

新しい/ dev / null特殊ファイルを(別の名前で)作成します

mknod /dev/newnull c 1 3
chmod 777 /dev/newnull

継続的に作成されたものの上に(ルートとして)移動します:

mv -f /dev/newnull /dev/null

そして、それからしかリブートできません(適切な/ dev / nullファイルがないとリブートしないでください。通常は簡単ではありません)[そのステップを忘れました。もちろん必要です。リマインダーをありがとう@ Random832!]

最後にリブートする必要があります。「/ dev / null」を開いたまま既存のプログラムを削除し、後で置き換えてもファイルシステムに書き込み、そのファイルシステムを少しずついっぱいにしていきます。 、ファイルを削除するときのように、そのファイル記述子を開いたままのプログラムは、ファイル名が新しいファイルを指している場合でも、以前のiノードに書き込むことができます)


2
彼はその後もサーバーを再起動する必要があります-通常のファイルへの書き込みを開始したものはすべて、削除されたファイルへの書き込みを継続し、ディスク容量を使い果たします。
-Random832

Random832 @:非常に真の、しかし、代わりに新しい正しい/ devの/ nullにファイルをした後、少なくとも再起動がはるかに簡単です...(多くのプログラムやスクリプトが正しく動作するためにそれに依存)
オリヴィエ・デュラック

8

実行lsof /dev/nullして、それを開いているプロセスがあるかどうかを確認できますが、リアルタイムで何が起こっているかは表示されません。

別のオプションは、デバイスを作成して所定の位置に移動することです。

mknod /dev/null.tmp c 1 3 && mv /dev/null.tmp /dev/null

しかし、私は最初にシステムを壊しているものを知りたいと思います。最近、これを引き起こしている可能性のある何かを変更しましたか?


7

再作成できない理由は、次の/dev/nullように何かが連続して書き込みを行っているためです。

echo "foo" > /dev/null

ファイルの内容を調べると、どのプロセスであるかがわかります。

今のところシステムを修正するには、次の手順に従ってください。

  1. システムをシャットダウンする
  2. で起動 init=/bin/bash
  3. 再マウント/書き込み可能
  4. charデバイスを作成します
  5. リブート

/ dev / nullが削除された方法を判断するために、システムを徹底的に調べることを強くお勧めします。システムが危険にさらされていないことを確認し、システムのログを徹底的に確認してください。


4

archlinuxシステムで原因と修正を見つけました。

bashを使用し、HISTFILE = / dev / nullが環境にある場合、$ HISTFILESIZEまたは$ HISTSIZEを超えるコマンドを実行しないでください。HISTFILEが/ dev / nullのときにbashで$ HISTFILESIZEよりも多くのコマンドを実行し、bashを終了した場合、bashは/ dev / nullを別の場所に移動し、/ dev / nullをアクセス許可600の通常ファイルとして再作成します。

emacs 24.4でtrampを使用する場合、tramp-sh.elはHISTFILEを/ dev / nullに設定します。したがって、bashがrootのシェルであり、emacs 24.4でtrampを使用して多くのroot操作を行う場合、emacsを強制終了すると、trampはbashに/ dev / nullを削除させます。

.bashrcまたはemacs 24.4などのプログラムでHISTFILEが/ dev / nullに設定されているかどうかを確認してください。

私の場合、シェルをzshに変更すると、trampがemacs 24.4でbashが/ dev / nullを削除するという事実を回避できます。


HISTORYを/ dev / nullに書き込む理由はありません。HISTORYを完全に無効にするには、HISSIZEを「0」に設定する必要があります。
ティムヘーゲル

unset HISTFILE/ dev / nullに何もせずに、履歴を無効にすることもできます。
マイケルハンプトン

ただし、emacs 24.4のtramp-sh.elはHISTFILEを/ dev / nullに設定しますが、今のところそれについてできることは何もありません。問題を回避するために、/ bin / dashを/ bin / shにシンボリックリンクしました。
クロケット
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.