我在网络上有十几台单板计算机，运行 Debian（squeeze），并通过 ssh 访问它们（ssh 服务器是 dropbear）。这些计算机的硬件配置如下：1.2 GHz x86 处理器、1GB RAM 和 4GB 闪存驱动器，格式化为 ext2（我避免使用 ext3，以防止日志记录增加闪存写入压力），驱动器上还有一个交换分区。
通常情况下，我使用的设置运行良好，我可以访问所有计算机。偶尔会有一个计算机阻止访问。我尝试通过 ssh（putty）连接时，系统会提示我登录，我输入用户名和密码，系统会响应“拒绝访问”，还会拒绝 ~/.ssh/authorized_keys 中的任何公钥。凭据与之前一样正确。计算机响应 ping，putty 识别服务器公钥，这对我来说意味着系统仍在运行。重新启动服务器可以解决问题，我可以再次登录。（我尝试了将 shutdown -r now 放在 root crontab 中的临时修复方法，但一旦发生挂起，这似乎无法可靠地运行）但是，一旦我重新启动，系统日志中似乎都没有任何信息表明发生了什么，日志在那段时间内都是空的，就好像系统崩溃了一样。
系统上运行的某些自定义软件似乎停止工作了（这就是我想使用 ssh 的原因）。我假设这个程序是问题的根源，但我不确定它是如何导致问题的，以及如何调试正在发生的事情。
我能想到的最可能的解释是，另一个程序中存在内存泄漏，从而阻止 dropbear 生成新的登录 shell（并阻止 crontab 执行关机），因为没有足够的可用内存。但查看其他（正在运行的）计算机的内存使用情况，似乎没有任何有意义的内存增加来表明泄漏（除非它是一个非常大、快速发生且罕见的泄漏）。我认为当操作系统内存不足时，它会重新启动系统或终止进程（Linux 内核会重新启动，对吧？）。我想知道的另一件事是，它们从闪存驱动器运行是否会产生一些影响，尤其是交换分区（我认为我应该删除它以防止闪存磨损），但闪存驱动器还很新（约 1 个月），我认为磨损还不是一个因素。
有谁知道是什么原因导致了这些症状，可能是内存泄漏，或者是其他我没想到的原因。有谁知道有什么方法可以尝试调试问题并找出更多有关问题的信息吗？
答案1
事实证明，问题与我使用的特定闪存驱动器有关。它们上面有特殊的“U3”垃圾，如果没有完全卸载，显然会导致 Linux 出现问题。我决定还是切换到更“实时”类型的安装会更好。现在我在启动时将根文件系统传输到 RAM 中并从那里运行，因此闪存驱动器对于系统继续运行来说并不是必不可少的。