Ich habe etwa ein Dutzend Single-Board-Computer in einem Netzwerk, auf dem Debian (Squeeze) läuft, und greife über SSH darauf zu (der SSH-Server ist Dropbear). Um eine Vorstellung von der Hardware dieser Computer zu geben: Sie sind 1,2 GHz x86-Prozessoren, 1 GB RAM und 4 GB Flash-Laufwerke, formatiert als ext2 (ich habe ext3 vermieden, um die zusätzliche Flash-Schreibbelastung durch Journaling zu vermeiden). Auf dem Laufwerk befindet sich außerdem eine Swap-Partition.
Normalerweise funktioniert das von mir verwendete Setup einwandfrei und ich kann auf alle Computer zugreifen. Hin und wieder wird der Zugriff jedoch verhindert. Folgendes passiert: Ich versuche, mich über SSH (Putty) zu verbinden und erhalte die Anmeldeaufforderung. Ich gebe Benutzernamen und Kennwort ein und die Antwort lautet „Zugriff verweigert“. Außerdem werden alle öffentlichen Schlüssel in ~/.ssh/authorized_keys abgelehnt. Die Anmeldeinformationen sind korrekt, da sie zuvor funktioniert haben. Der Computer antwortet auf Pings und Putty erkennt den öffentlichen Schlüssel des Servers, was für mich bedeutet, dass das System noch läuft. Ein Neustart des Servers behebt das Problem und ich kann mich erneut anmelden. (Ich habe versucht, vorübergehend „shutdown -r now“ in die Root-Crontab einzufügen, aber dies scheint nicht zuverlässig ausgeführt zu werden, wenn das System einmal hängen geblieben ist.) Nach dem Neustart scheinen jedoch in keinem der Systemprotokolle Informationen zu enthalten zu sein, die darauf hinweisen, was passiert ist. Die Protokolle sind für diesen Zeitraum einfach leer, als ob das System abgestürzt wäre.
Auf dem System läuft eine benutzerdefinierte Software, die anscheinend nicht mehr funktioniert (weshalb ich überhaupt SSH verwenden wollte). Ich gehe davon aus, dass dieses Programm die Ursache der Probleme ist, bin mir aber nicht sicher, wie es die Ursache sein könnte und wie ich das Problem beheben kann.
Die wahrscheinlichste Erklärung, die mir einfällt, ist, dass es in dem anderen Programm ein Speicherleck gibt, das dann verhindert, dass Dropbear eine neue Login-Shell startet (und Crontab daran hindert, Shutdown auszuführen), da nicht genügend freier Speicher vorhanden ist. Aber wenn man sich die Speichernutzung der anderen (funktionierenden) Computer ansieht, scheint es keine nennenswerte Speicherzunahme zu geben, die auf ein Leck hindeutet (es sei denn, es handelt sich um ein sehr großes, schnell auftretendes und seltenes Leck). Ich würde denken, dass das Betriebssystem das System neu startet oder Prozesse beendet, wenn der Speicher voll ist (der Linux-Kernel startet doch neu, oder?). Die andere Sache, die ich mich frage, ist, ob die Tatsache, dass sie von einem Flash-Laufwerk ausgeführt werden, einen Einfluss haben könnte, insbesondere die Swap-Partition (die ich meiner Meinung nach entfernen sollte, um Verschleiß des Flash-Laufwerks zu verhindern), aber die Flash-Laufwerke sind jung (~1 Monat) und ich glaube nicht, dass Verschleiß bereits ein Faktor wäre.
Hat jemand eine Idee, was diese Symptome verursachen könnte, ob es an einem Speicherverlust liegen könnte oder an etwas anderem, woran ich nicht gedacht habe? Und kennt jemand eine Methode, um das Problem zu debuggen und mehr Informationen darüber zu erhalten, was schief läuft?
Antwort1
Es stellte sich heraus, dass das Problem etwas mit den speziellen Flash-Laufwerken zu tun hatte, die ich verwendete. Sie hatten diesen speziellen „U3“-Müll darauf, der anscheinend unter Linux Probleme verursachen kann, wenn er nicht vollständig deinstalliert wird. Ich entschied, dass es sowieso besser wäre, auf eine „Live“-Installation umzusteigen. Jetzt übertrage ich das Root-Dateisystem beim Booten in den RAM und führe es von dort aus aus, sodass das Flash-Laufwerk für den weiteren Betrieb des Systems nicht kritisch ist.