本番サーバーで突然/dev/null
は通常のファイルになり、このためにsshdサービスが停止し、サーバーにログインできなくなりました。また、以下の手順を実行して、キャラクターデバイスファイルに設定し直しました。
rm -rf /dev/null
mknod /dev/null c 1 3
rm
コマンドを実行するとすぐに/dev/null
は、mknod
を実行する前に、通常のファイルとして再作成されています。これがどのように起こっているのか、どのファイルがこのファイルを作成しているのかはわかりません。したがって、この問題を解決するまで、/dev/null
をキャラクターデバイスファイルとして。
(rm)/ dev/nullを削除すると、実行中のプログラムやスクリプトで ">/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ノードに書き込むことができます)
lsof /dev/null
開いているプロセスがあるかどうかを確認しますが、リアルタイムで何が起こっているかはわかりません。
別のオプションは、デバイスを作成して所定の位置に移動することです。
mknod /dev/null.tmp c 1 3 && mv /dev/null.tmp /dev/null
しかし、私は最初にシステムを壊しているものを知りたいと思います。これを引き起こしている可能性のある何かを最近変更しましたか?
再作成できない理由/dev/null
は、次のように何かが連続して書き込んでいる可能性があります。
echo "foo" > /dev/null
ファイルの内容を調べると、それがどのプロセスであるかがわかります。
今のところシステムを修正するには、次の手順に従います。
init=/bin/bash
システムを徹底的に調べて、/ dev/nullがどのように削除されたかを判断することを強くお勧めします。システムが危険にさらされていないことを確認し、システムのログを徹底的に確認します。
Archlinuxシステムで原因と修正を見つけました。
Bashを使用し、HISTFILE =/dev/nullが環境内にある場合は、$ HISTFILESIZEまたは$ HISTSIZEより多くのコマンドを実行しないでください。 HISTFILEが/ dev/nullのときにbashで$ HISTFILESIZEより多くのコマンドを実行し、bashを終了した場合、bashは/ dev/nullを別の場所に移動し、権限600で/ dev/nullを通常のファイルとして再作成します。
Emacs 24.4でtrampを使用する場合、tramp-sh.elはHISTFILEを/ dev/nullに設定します。したがって、bashがrootのシェルであり、emacs 24.4でtrampを使用して多くのroot操作を行う場合、emacsをkillすると、trampはbashに/ dev/nullを削除させます。
HISTFILEが.bashrcまたはemacs 24.4などのプログラムで/ dev/nullに設定されているかどうかを確認してください。
私の場合、シェルをzshに変更すると、trampがemacs 24.4のbashを/ dev/nullに削除するという問題を回避できます。