/ dev / null文件变为常规文件

在我们的生产服务器中，服务器突然/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”，并且仍将写入文件系统，从而逐渐填充该文件系统）（确实，就像删除文件时一样，即使文件名现在指向新的inode，仍打开该文件描述符的任何程序仍将能够写入前一个inode。

您可以运行lsof /dev/null并查看是否有一个打开的进程，但它不会实时显示正在发生的事情。

另一种选择是制作设备并将其移动到位。

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

但是我想知道什么首先破坏了系统。您最近是否更改了可能导致此问题的任何内容？

您无法重新创建的原因/dev/null很可能是某些东西连续不断地向其写入，如下所示：

echo "foo" > /dev/null

检查文件的内容将告诉您文件的处理过程。

要暂时修复您的系统，请按照以下说明进行操作：

1. 关闭系统
2. 用启动 init=/bin/bash
3. 重新安装/可写
4. 创建字符设备
5. 重启

我强烈建议对系统进行深入检查，以确定/ dev / null如何被删除。确保您的系统没有受到威胁，请彻底检查系统日志。

我在我的archlinux系统上找到了原因和解决方法。

如果您使用bash并且HISTFILE = / dev / null在环境中，则执行的命令不应超过$ HISTFILESIZE或$ HISTSIZE。如果在HISTFILE为/ dev / null时在bash上执行的命令多于$ HISTFILESIZE，则退出bash时，bash会将/ dev / null移至其他位置，并将/ dev / null重新创建为具有权限600的常规文件。

如果在emacs 24.4上使用流浪汉，tramp-sh.el会将HISTFILE设置为/ dev / null。因此，如果bash是root的外壳程序，并且如果您在emacs 24.4上使用tramp进行了许多root操作，则在杀死emacs时，tramp使bash删除/ dev / null。

请检查.bashrc或emacs 24.4之类的程序中HISTFILE是否设置为/ dev / null。

就我而言，将外壳程序更改为zsh可以解决以下问题：流浪汉使bash在emacs 24.4上删除/ dev / null。