我在一台运行Debian（挤压）的networking上有十几台单板计算机，并通过ssh访问它们（ssh服务器是dropbear）。 要了解这些计算机的硬件，他们是1.2 GHz的x86处理器，1GB的RAM和4GB的闪存驱动器格式化为ext2（我避免了ext3，以防止从日志添加的闪存写入压力），也有一个交换分区驱动器。
通常我使用的设置很好，我可以访问所有的计算机。 每过一段时间一次都会阻止访问。 会发生什么是我试图连接通过SSH（腻子），它给了我login提示，我input用户名和密码，它响应“拒绝访问”，它也将拒绝〜/ .ssh / authorized_keys中的任何公钥。 凭据是正确的，因为他们以前的工作。 计算机响应ping和putty识别服务器公钥，这意味着系统仍在运行。 重新启动服务器可以解决问题，我可以再次login。 （我尝试暂时修复把shutdown -r放入根crontab，但是一旦发生挂起，这似乎不能可靠地运行）。但是，一旦我重新启动，似乎没有任何系统日志中的任何信息为了表明发生了什么事情，日志在这段时间内是空的，就好像系统崩溃了一样。
有一些定制软件在系统上运行似乎停止工作（这就是为什么我想ssh开始）。 我假设这个程序是问题的根源，但我不确定它将如何导致它，以及如何debugging正在发生的事情。
我能想到的最可能的解释是，在另一个程序中存在内存泄漏，从而防止dropbear产生新的loginshell（并且执行closures的crontab），因为没有足够的可用内存。 但是看看其他（工作）计算机的内存使用情况，似乎没有任何有意义的内存增加来指示泄漏（除非它是一个非常大的，快速行为和罕见的泄漏）。 我会认为，当操作系统内存不足时，它会重新启动系统或终止进程（Linux内核重新启动？）。 另一件我想知道的事情是，如果他们的闪存驱动器的事实，可能会有一些影响，特别是交换分区（我认为我应该删除，以防止闪存磨损），但闪存驱动器是年轻的（〜 1个月），我不认为磨损是一个因素呢。
有没有人知道什么可能导致这些症状，如果它可以通过内存泄漏，或其他我没有想到的东西。 有没有人知道一种方法来尝试debugging问题，并找出更多的信息，哪里出了问题？
事实certificate，这个问题与我使用的特定闪存驱动器有关。 他们有这个特殊的'U3'垃圾，显然可以导致在Linux上的问题，如果它没有完全卸载。 我决定，反而更好的切换到更“活”的types安装。 现在我在启动时将根文件系统转换为ram，并从中运行，因此闪存对于系统继续运行并不重要。