Die Datei / dev / null wurde zur regulären Datei

In unserer Produktion Server wurde plötzlich /dev/nulleine reguläre Datei und aufgrund dieser sshd-Dienst wurde gestoppt und nicht in der Lage, den Server anzumelden. Wir haben auch versucht, die folgenden Schritte auszuführen, um die Geräte-Zeichendatei wiederherzustellen.

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

Sobald wir den rmBefehl ausführen, /dev/nullwird er als reguläre Datei neu erstellt, bevor er ausgeführt werden mknodkann. Wir können nicht herausfinden, wie dies geschieht und welche Komponente diese Datei erstellt. Bis wir dieses Problem gelöst haben, können wir keine /dev/nullCharacter Device-Datei erstellen .

Wenn Sie (rm) / dev / null löschen, erstellen alle Programme / Skripte, die ausgeführt werden und "> / dev / null" oder eine gleichwertige Datei benötigen, eine neue (reguläre) Datei mit diesem Namen. Und die können jederzeit laichen (und manche können auch ständig darauf schreiben)

Um sie zu schlagen:

Sie erstellen eine neue / dev / null-Spezialdatei (unter einem anderen Namen)

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

und du verschiebst es über (als root) die kontinuierlich erstellten:

mv -f /dev/newnull /dev/null

Und nur dann können Sie neu starten (nicht ohne eine richtige / dev / null-Datei neu starten ... es ist normalerweise nicht einfach) [Ich habe diesen Schritt vergessen, was natürlich notwendig ist. Danke an Random832 für die Erinnerung!]

Sie müssen am Ende einen Neustart durchführen, um das vorhandene Programm zu entfernen, das weiterhin ein "/ dev / null" geöffnet hat und weiterhin in das Dateisystem schreibt, obwohl Sie es anschließend ersetzt haben, und dieses Dateisystem nach und nach auffüllt Wie beim Löschen einer Datei kann jedes Programm, das diesen Dateideskriptor noch geöffnet hat, weiterhin in den früheren Inode schreiben, obwohl der Dateiname jetzt auf den neuen verweist.

Sie könnten laufen lsof /dev/nullund sehen, ob ein Prozess geöffnet ist, der Ihnen jedoch nicht in Echtzeit anzeigt, was gerade passiert.

Eine andere Möglichkeit wäre, das Gerät zu machen und an Ort und Stelle zu bewegen.

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

Aber ich würde zuerst wissen wollen, was das System bricht. Haben Sie in letzter Zeit etwas geändert, das dies verursachen könnte?

Der Grund, warum Sie nicht neu erstellen können, /dev/nullist wahrscheinlich, dass ständig etwas darauf schreibt:

echo "foo" > /dev/null

Wenn Sie den Inhalt der Datei untersuchen, erfahren Sie, um welchen Prozess es sich handelt.

Befolgen Sie diese Anweisungen, um Ihr System vorerst zu reparieren:

1. Fahren Sie das System herunter
2. booten mit init=/bin/bash
3. remount / beschreibbar
4. Erstellen Sie das char-Gerät
5. neustarten

Es wird dringend empfohlen, das System einer eingehenden Prüfung zu unterziehen, um festzustellen, wie / dev / null gelöscht wurde. Stellen Sie sicher, dass Ihr System nicht gefährdet ist, und überprüfen Sie das Protokoll Ihres Systems gründlich.

Ich habe die Ursache und den Fix auf meinem Archlinux-System gefunden.

Wenn Sie bash verwenden und HISTFILE = / dev / null in der Umgebung ist, sollten Sie nicht mehr Befehle als $ HISTFILESIZE oder $ HISTSIZE ausführen. Wenn Sie mehr Befehle als $ HISTFILESIZE für bash ausgeführt haben, während HISTFILE / dev / null ist, und Sie bash beendet haben, verschiebt bash / dev / null an eine andere Stelle und erstellt / dev / null als reguläre Datei mit der Berechtigung 600 neu.

Wenn Sie Tramp auf Emacs 24.4 verwenden, setzt tramp-sh.el HISTFILE auf / dev / null. Wenn also bash die Shell für root ist und Sie viele Root-Operationen mit tramp auf Emacs 24.4 ausführen, bewirkt tramp beim Beenden von Emacs, dass bash / dev / null löscht.

Bitte überprüfen Sie, ob HISTFILE in .bashrc oder in Programmen wie emacs 24.4 auf / dev / null gesetzt ist.

In meinem Fall funktioniert das Ändern der Shell in zsh um die Tatsache herum, dass tramp bash delete / dev / null auf Emacs 24.4 macht.