在我们的生产服务器突然/dev/null成为一个普通的文件，由于这个sshd服务停止，无法login服务器。 而且我们也试着按照以下步骤来configuration回字符设备文件，
rm -rf /dev/null mknod /dev/null c 1 3
只要我们运行rm命令/dev/null在mknod可以运行之前就被重新创build为常规文件。 我们无法弄清楚这是怎么发生的以及哪个组件正在创build这个文件。 所以，直到我们解决这个问题，我们无法创build/dev/null作为字符设备文件。
删除（rm）/ dev / null时，任何正在运行并且需要“> / dev / null”或等效的程序/脚本将重新创build一个具有该名称的新（常规）文件。 而且这些可以随时产卵（有些人也可以不断写信给它）
打败他们：
你创build一个新的/ dev / null特殊文件（以不同的名字）
mknod /dev/newnull c 1 3 chmod 777 /dev/newnull
你把它（作为根）不断创build的：
mv -f /dev/newnull /dev/null
只有这样你才能重新启动（不要在没有正确的/ dev / null文件的情况下重新启动…通常不容易）[我忘记了这一步，这当然是必要的。 感谢@ Random832提醒！]
最后需要重新启动，以摆脱仍然有“/ dev / null”打开的现有程序，并且仍然会写入文件系统，即使您之后replace了它，一点一点地填充该文件系统） ，就像删除文件时一样，即使文件名现在指向新的文件，任何仍然打开文件描述符的程序仍然可以写入前一个inode，
你不能重新创build/dev/null原因可能是这样的东西连续写入：
echo "foo" > /dev/null
检查文件的内容将告诉你它可能是什么进程。
要立即修复您的系统，请按照以下说明进行操作：
init=/bin/bash 我强烈build议对系统进行强烈的检查，以确定/ dev / null如何被删除。 确保你的系统没有受到危害，彻底检查你的系统日志。
你可以运行lsof /dev/null ，看看是否有一个进程打开它，但是它不会实时显示你正在发生的事情。
另一种select是制作设备并将其移动到位。
mknod /dev/null.tmp c 1 3 && mv /dev/null.tmp /dev/null
但我想知道什么是首先打破系统。 你最近有没有改变可能造成这种情况？
我find了我的archlinux系统的原因和修复。
如果使用bash并且HISTFILE = / dev / null在环境中，则不应执行比$ HISTFILESIZE或$ HISTSIZE更多的命令。 如果在HASHFILE为/ dev / null且您退出bash的情况下执行了比$ HISTFILESIZE更多的命令，则bash会将/ dev / null移动到其他位置，并将/ dev / null重新创build为具有权限600的常规文件。
如果你在emacs 24.4上使用tramp，tramp-sh.el将HISTFILE设置为/ dev / null。 因此，如果bash是root的shell，并且如果你在emacs 24.4上用tramp做了很多root操作，当你杀死emacs时，tramp会让bash删除/ dev / null。
请检查HISTFILE是否在.bashrc中或者像emacs 24.4这样的程序中被设置为/ dev / null。
在我的情况下，将shell更改为zsh的方法是在emacs 24.4上，tramp使bash删除/ dev / null。