Il file / dev / null è diventato un file normale

Nel nostro server di produzione è /dev/nulldiventato improvvisamente un file normale e a causa di questo servizio SSH è stato arrestato e non è stato in grado di accedere al server. Inoltre, abbiamo provato a eseguire i passaggi seguenti per configurare di nuovo il file del dispositivo carattere,

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

Non appena eseguiamo il rmcomando /dev/nullviene ricreato come un normale file prima che mknodpossa essere eseguito. Non possiamo capire come questo accada e quale componente sta creando questo file. Quindi, fino a quando non risolviamo questo problema, non siamo in grado di creare /dev/nullcome file dispositivo carattere.

Quando si elimina (rm) / dev / null, qualsiasi programma / script in esecuzione e che necessita di "> / dev / null" o equivalente creerà nuovamente un nuovo file (normale) con quel nome. E quelli possono generarsi in qualsiasi momento (e alcuni possono anche scriverlo continuamente)

Per batterli:

si crea un nuovo file speciale / dev / null (con un nome diverso)

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

e lo sposti (come root) su quelli continuamente creati:

mv -f /dev/newnull /dev/null

E solo allora puoi riavviare (non riavviare senza un file / dev / null corretto sul posto ... di solito non è facile) [Ho dimenticato quel passaggio, che è ovviamente necessario. Grazie @ Random832 per il promemoria!]

È necessario riavviare alla fine, per sbarazzarsi del programma esistente che avrà ancora un "/ dev / null" aperto e continuerà a scrivere nel filesystem anche se lo hai sostituito in seguito, riempiendo quel file system a poco a poco) (Infatti , come quando si elimina un file, qualsiasi programma che ha ancora quel descrittore di file aperto sarà comunque in grado di scrivere sull'inode precedente, anche se il nome del file punta ora a quello nuovo)

Potresti eseguire lsof /dev/nulle vedere se c'è un processo che lo ha aperto ma non ti mostrerebbe cosa sta succedendo in tempo reale.

Un'altra opzione sarebbe quella di rendere il dispositivo e spostarlo in posizione.

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

Ma vorrei sapere prima cosa sta rompendo il sistema. Hai cambiato qualcosa di recente che potrebbe causare questo?

Il motivo per cui non /dev/nullè possibile ricreare è probabile che qualcosa ci scriva continuamente in questo modo:

echo "foo" > /dev/null

Esaminare il contenuto del file ti dirà quale processo potrebbe essere.

Per risolvere il tuo sistema per ora, segui queste istruzioni:

1. spegnere il sistema
2. avviare con init=/bin/bash
3. rimonta / scrivibile
4. crea il dispositivo char
5. riavvio

Consiglio vivamente di fare un intenso esame del sistema per determinare come / dev / null è stato cancellato. Assicurati che il tuo sistema non sia compromesso, controlla attentamente il registro del tuo sistema.

Ho trovato la causa e la correzione sul mio sistema archlinux.

Se usi bash e HISTFILE = / dev / null è in ambiente, non dovresti eseguire più comandi di $ HISTFILESIZE o $ HISTSIZE. Se hai eseguito più comandi di $ HISTFILESIZE su bash mentre HISTFILE è / dev / null e sei uscito da bash, bash sposta / dev / null da qualche altra parte e ricrea / dev / null come file normale con autorizzazione 600.

Se usi tramp su emacs 24.4, tramp-sh.el imposta HISTFILE su / dev / null. Pertanto, se bash è la shell per root e se si eseguono molte operazioni root con tramp su emacs 24.4, quando si uccide emacs, il tramp rende bash delete / dev / null.

Controlla se HISTFILE è impostato su / dev / null in .bashrc o in programmi come emacs 24.4.

Nel mio caso, cambiare la shell in zsh si basa sul fatto che tramp rende bash delete / dev / null su emacs 24.4.