今天我们的一台生产机器（Amazon EC2）宕机了，我无法启动该实例，因为我无法进入 SSH，连接被拒绝，我不知道该怎么办，过了一段时间我才能够启动该实例 -（好吧，简短而甜蜜）。
我不知怎么就找到了问题的根本原因，就是/dev/urandom文件丢失，因此SSH无法启动。我必须在重启时创建这个文件，我通过在现有启动 (init) 脚本中添加几行代码来创建它，这样就可以启动并运行服务器，这意味着我可以通过 SSH 进入该框。
我需要专家就以下问题提供建议，请随时向我提供更多信息：
- 我应该保留我在其中一个初始化脚本文件中编写的那些代码行吗？
- 文件丢失的原因可能是什么
/dev/urandom？ - 我该怎么做才能避免将来再次出现这种情况？
谢谢。
更新：
对于那些想知道我写了什么的人：
#!/bin/bash
cd /dev ; /sbin/MAKEDEV urandom ; /etc/init.d/ssh start
答案1
我建议保留代码。我知道建议保留代码听起来很傻，但你/dev/urandom消失的事实确实很奇怪，而且可能再次发生。修改您的代码，使其发出日志消息，以便在将来需要重新创建设备文件时您无法忽略这些消息。
删除您的文件没有任何正当理由/dev/urandom。我们所能期望的最好的办法是配置一个工具，例如puppet或，chef以便从 tarball 中写入文件目录，然后首先在扩展 tarball 时完全清除该目录。（我认为这种使用是对该工具的严重配置错误。）但任何以 身份运行的进程都root有权删除该文件，因此几乎可以是任何东西。
您可以配置auditd监视目录中文件的创建、删除和重命名/dev/。将规则放入/etc/audit/audit.rules以配置持久监视：
-w /dev/ -p wa
有关配置审计监视列表的完整详细信息，请参阅auditctl(8)；它非常易于配置，您可能需要根据系统调整配置，以便“标准”事件不会扰乱您的审计日志。
另一个选择是使用程序设置immutable文件的属性chattr(1)。删除该文件的任何程序或工具都可能不是immutable在删除文件之前尽力删除该属性。
答案2
通常，当您升级操作系统时会发现类似的问题，并且由于某种原因升级中断。在 AWS (EC2) 中，您不应该升级他们提供的内核。您最近尝试升级操作系统了吗？最好找到丢失 /dev/urandom 的实际原因并修复它。在此之前，请将代码保留在 init 脚本中。让我们知道进展如何。