/ dev / null file se convirtió en archivo regular

En nuestro servidor de producción, de repente se /dev/nullconvirtió en un archivo normal y debido a este servicio sshd se detuvo y no pudo iniciar sesión en el servidor. Y también intentamos los pasos a continuación para volver a configurar el archivo del dispositivo de caracteres,

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

Tan pronto como ejecutamos, el rmcomando /dev/nullse vuelve a crear como un archivo normal antes de que mknodpueda ejecutarse. No podemos entender cómo sucede esto y qué componente está creando este archivo. Entonces, hasta que resolvamos este problema, no podremos crear /dev/nullcomo archivo de dispositivo de caracteres.

Cuando elimine (rm) / dev / null, cualquier programa / script que se esté ejecutando y que necesite "> / dev / null" o equivalente volverá a crear un nuevo archivo (regular) con ese nombre. Y esos pueden aparecer en cualquier momento (y algunos también pueden escribirle continuamente)

Para vencerlos:

crea un nuevo archivo especial / dev / null (con un nombre diferente)

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

y lo mueves (como root) a los creados continuamente:

mv -f /dev/newnull /dev/null

Y solo entonces puede reiniciar (no reinicie sin un archivo / dev / null adecuado ... generalmente no es fácil) [Olvidé ese paso, que por supuesto es necesario. ¡Gracias @ Random832 por el recordatorio!]

Debe reiniciar al final, para deshacerse del programa existente que todavía tendrá un "/ dev / null" abierto y aún escribirá en el sistema de archivos a pesar de que lo reemplazó después, llenando ese sistema de archivos poco a poco) (De hecho , como al eliminar un archivo, cualquier programa que todavía tenga ese descriptor de archivo abierto podrá escribir en el inodo anterior, aunque el nombre del archivo ahora apunte al nuevo)

Puede ejecutar lsof /dev/nully ver si hay un proceso que lo tiene abierto, pero no le mostrará lo que está sucediendo en tiempo real.

Otra opción sería hacer el dispositivo y moverlo en su lugar.

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

Pero me gustaría saber qué es lo que está rompiendo el sistema primero. ¿Has cambiado algo recientemente que pueda estar causando esto?

La razón por la que no puede recrear /dev/nulles probable que algo le escriba de manera continua:

echo "foo" > /dev/null

Examinar el contenido del archivo le dirá qué proceso podría ser.

Para arreglar su sistema por ahora, siga estas instrucciones:

1. apagar el sistema
2. arrancar con init=/bin/bash
3. remontar / escribible
4. crear el dispositivo char
5. reiniciar

Sugeriría encarecidamente hacer un examen intenso del sistema para determinar cómo / dev / null se eliminó. Asegúrese de que su sistema no esté comprometido, verifique el registro de su sistema a fondo.

Encontré la causa y la solución en mi sistema archlinux.

Si usa bash y HISTFILE = / dev / null está en el entorno, no debe ejecutar más comandos que $ HISTFILESIZE o $ HISTSIZE. Si ejecutó más comandos que $ HISTFILESIZE en bash mientras HISTFILE es / dev / null y salió de bash, bash se mueve / dev / null a otro lugar y recrea / dev / null como un archivo normal con permiso 600.

Si usa tramp en emacs 24.4, tramp-sh.el establece HISTFILE en / dev / null. Por lo tanto, si bash es el shell de root y si realiza muchas operaciones de root con tramp en emacs 24.4, cuando elimina emacs, tramp hace que bash elimine / dev / null.

Compruebe si HISTFILE está configurado en / dev / null en .bashrc o en programas como emacs 24.4.

En mi caso, cambiar el shell a zsh funciona alrededor del hecho de que vagabundo hace que bash delete / dev / null en emacs 24.4.