TS-453be (4.4.3.1354) UNGEPLANTE SELBSTSTÄNDIGE NEUSTARTS

Zitat von Kamikaze01

Kann einen guten WLAN Stick empfehlen?

Schau in der Kompatibilitätsliste deines NAS nach welche Sticks freigegeben sind.

Zitat von Kamikaze01

sowieso nur ein "kill" per Tastendruck am NAS

Wenn das Regelmäßig passiert, würde es mich nicht wundern wenn das Dateisystem mittlerweile einen Schaden hat.

Zitat von Kamikaze01

Liegt das am WLAN Dongle!?!

Konnte im Kernelprotokoll keine Hinweise auf Ursache für gelegentliche Neustarts erkennen, und damit den WLAN Dongle ebenfalls nicht als Verursacher erkennen.

Zitat von Kamikaze01

Dann verliert er aber auch dort manchmal den Gateway und dann hilft sowieso nur ein "kill" per Tastendruck am NAS

Kenne jetzt nicht Deine Konfiguration noch die Ursache für Verlust des Gateway-Eintrages. Es leuchtet mir ohne Zusatzinfos noch nicht ein, warum dann ein kill per Tastendruck am NAS die einzige Lösung sein solle.

• Was soll sich dadurch lösen?
• Warum solle kein manueller Eintrag eines Gateways in solch einem Zustand nicht möglich sein und nicht eine Alternative darstellen?

Zitat von Kamikaze01

Warnung 14.07.2020 10:45:21 System 127.0.0.1 Power NAS Power Status [Power] The system was not shut down properly last time.

Auch ich kenne gelegentliche, spontane Restarts meines TS-453Be (und meines TS-431P) mit QTS 4.4.1. Ich kenne Ursachen bei mir und habe diese weitgehend unter Kontrolle gebracht. Die Ursache(n) hatte ich mir selbst eingebrockt. Die spontanen Restarts bei mir fand ich nirgends dokumentiert und waren Überlastsituationen des jeweiligen Systems. Beim TS-431P tritt dies bei mir nun seltener als einmal pro Halbjahr auf. Wenn ich clamav auch noch deaktiviere, dürfte ich keine Überlast mehr darauf erwarten und damit auch keine spontanen Restarts. Bei meinem TS-453Be kann ich keine aktuellen Daten liefern, weil ich diesen derzeit selten einschalte. Zuvor traten solche Restarts etwa noch alle 6 Wochen bei mir auf, also deutlich seltener als bei Dir. Weiß jetzt nicht, ob diese Meldung in der gleichen Anwendung und Kategorie eingeordnet war wie bei Dir.

• Bereinigst Du dann jedesmal Dein Dateisystem, wenn Du diese Warnung erhältst?
• Mit wieviel Hauptspeicher betreibst Du Dein Gerät?
• Hast Du eher viele oder eher wenige Dienste darauf am Laufen und wie hoch ist die durchschnittliche CPU-Last und die durchschnittliche Hauptspeicherauslastung?
• Oder hast Du ein instabiles Stromnetz und bräuchtest eine USV?

Zitat von Kamikaze01

Warum diese aber einfach nicht dokumentiert sind verstehe ich nicht

Für Entwickler scheinen solche Konfigurationen selbstverständlich und selbsterklärend. Habe selbst schon beruflich vor Jahrzehnten als Entwickler gearbeitet. Für embedded Systeme die üblicherweise ohne lokalen Benutzer oder lokalen Administrator betrieben werden, wie z.B. auch eine Telefonanlage, gibt es i.d.R. lokale Systemüberwachung, die gegebenenfalls einfache Behebungen versuchen, und wenn sonst keine Versuche klappen, in einen definierten Zustand zurück kehren. Dies ist oftmals mit einem Reboot verbunden, entweder in den normalen Betriebszustand oder in einen Wartungszustand. Ein Reboot in den normalen Betriebszustand ist am Häufigsten.

Wenn ich mich per Kommandozeile anmelde, sehe ich meiner Erinnerung nach 2-3 derartige Dienste am Laufen. Habe bislang nicht weiter recherchiert, in wie weit diese Dienste konfigurierbar sind, z.B. nach Schwellwerten und nach Zielzustand. Für die Konfiguration wäre entweder eine Konfigurationsdatei oder die Kommandozeile denkbar. Solche Dienste werden aber normalerweise nicht per Kommandozeile gestartet, sondern aus einem Bootskript beim Systemstart. Wenn es eine Konfigurationsdatei gibt, hat diese vermutlich den Dienstnamen als Teil des eigenen Namens mit mutmaßlich anderer Dateinamenserweiterung. Eine weitere Beobachtung ist, dass QTS hierfür wohl ein schlechtes Verhalten konfiguriert hat, mutmaßlich mit einem fehlerhaften Programm oder Programmmodus. Denn bei embedded Systemen würde üblicherweise der Restart sauber mit Betriebssystemmitteln erzwungen. Auch dies sollte bei QTS möglich sein. Aber tatsächlich scheint eine unsaubere, privilegierte Assemblersequenz den Restart auszulösen, ohne auch nur zu versuchen, die Dateisysteme sauber zu halten, so als wenn Du ohne Schalterbetätigung das Stromkabel abziehst und wieder ansteckst! Und das ist die Erklärung für die Warnung, die Du auf der GUI beim Neustart siehst. Daher ist es auch richtig und wichtig, dass Du (und ich) den Dateisystemcheck auf beschädigten Dateisystemen durchführst.

Fehlende Dokumentation kann entweder Absicht sein, oder der Arbeitsteilung, dem unzureichenden Qualitätsmanagement und/oder Fahrlässigkeit geschuldet sein. Für den normalen Anwender wäre eine solche Dokumentation eher verwirrend. Für den normalen Administrator kann die gleiche Wirkung auftreten. Für den fortgeschrittenen Administrator dagegen, der mit embedded Systemen vertraut ist, wäre es hilfreich. Und es wäre ausreichend, wenn in allgemeiner Administratorendoku ein Hinweis wäre, wo weiterführende Infos für fortgeschrittene Administratoren zu finden wären, und welche Namenskonventionen dafür gelten.

Zitat von Kamikaze01

Müsste eine Überlastung des Systems nicht ebenfalls im Log ersichtlich sein?

Nicht notwendigerweise. Eine Überlastung zeichnet sich ja gerade dadurch aus, das ein oder mehrere Betriebsmittel nicht (mehr) ausreichend zur Verfügung stehen. In einem solchen Zustand kann nicht gewährleistet werden, dass Protokolleinträge auch noch geschrieben werden oder vollständig seien. Eine Betrachtung der Prozesstabelle kann in solch einem Zustand vielleicht gerade noch funktionieren und daher den Verdacht der Überlastung bekräftigen. So bin ich bei mir auf die Spur gekommen.

Zitat von Kamikaze01

Ich muss an dieser Stelle auch zugeben, dass ich mein NAS mit 2x8GB RAM aufgerüstet habe und laut QNAP für dieses Model nur insgesamt max. 8GB zulässig sind. Darüber gibt es aber eigene Threats und mein NAS rennt eigentlich mit diesen beiden RAM seit Anfang an...

Wobei QNAP diese Angaben mutmaßlich ungeprüft von Intel übernommen hat. Steht so auch in der Architekturdatenbank von Intel für diesen Prozessor. Allerdings kenne ich keine Angaben aus der Architektur, die eine solche Begrenzung als folgerichtig erklären lassen, noch welches Verhalten erwartet wird, wenn der Prozessor mit mehr Hauptspeicher betrieben wird bzw. welche Vorkehrungen für einen stabilen Betrieb mit welchen Einschränkungen zu empfehlen wäre.

Auch ich habe dieses NAS mit 2x 16GB und mit 1x 16 GB betrieben. Habe kürzlich eine Speichererweiterung für ein älteres Notebook gekauft, die von diesem aber nicht unterstützt wird. Von daher kann ich es bei Gelegenheit bei diesem NAS mit 2x 8GB und mit 1x 8GB probieren. Denn ich habe keine Ahnung, wie belastbar die Angaben von Anwendern sind, die dieses NAS seit Jahren mit 16 (oder seltener 32) GB Hauptspeicher betreiben. Z.B. habe ich beobachtet, dass bei mir nie die 32 GB Hauptspeicher jemals verwendet werden. Auch in der Konfiguration mit 1x 16 GB wurde dieser nie voll genutzt. Eine Beobachtung der Prozesstabelle zeigte mir, dass wenn die Hauptspeichernutzung 15 GB überschreitet, der Punkt erreicht wird, an dem dieses NAS bei mir rebootet. Was ich bislang nicht probiert habe, ist, wie das System wo konfiguriert werden müsse, um beispielsweise den Speicherbereich von 15-16 GB für Hauptspeicherzwecke zu blockieren. Ich habe die (spekulative und ungeprüfte) Vermutung, dass ein Betrieb mit 32 GB stabil möglich sein solle, wenn die entsprechenden 1-2 Hauptspeicherbereiche blockiert würden. Eigentlich gibt es Hardwarekonventionen, die entsprechende Blockaden automatisch einrichten. Aber es sieht mir danach aus, als genüge dieses QNAP NAS nicht diesen Hardwarekonventionen. Auch habe ich noch nicht probiert, dieses NAS in einem anderen Modus zu betreiben, um Zugriff auf Systemfirmware (oder BIOS) zu erhalten, und in solch einem Zustand ein Hauptspeichertestprogramm zu starten. Dieses NAS unterstützt solche Betriebsarten, die solche Zugänge und Tests erlauben. Denn wenn die Mißachtung von solchen Hardwarekonventionen die Ursache wäre, müsste dies auch beim Hauptspeichertest in solch einem Zustand auftreten und reproduzierbar sein.

Kenne jetzt nicht die Artikel in der c't zum Test von QNAP TS-253D und anderen NAS. Dieses Modell ist das Nachfolgemodell von QNAP mit einem Nachfolgeprozessor, der unverändert die gleiche Begrenzung des Hauptspeichers behauptet. Laut c't konnte auch dieses Nachfolgemodell mit 16 GB Hauptspeicher erfolgreich betrieben werden.

Die Hardwarespezifikationen des TS-453Be sind ja bei QNAP ohnehin unvollständig. Ein Blick auf die verfügbaren Speicher im QNAP Shop für dieses Modell liefert indirekt die JEDEC-Spezifikation des Hauptspeichers, der sicher unterstützt wird. Diese halte ich für wichtig. Und ein Blick auf die Intel Architekturdatenbank zu diesem Prozessor liefert weitere Hinweise, welche Speicher möglicherweise unterstützt werden und welche sicher nicht.

Zitat von Kamikaze01

Warum habe ich in meinen Kernel-Logs eigentlich soviele tausend Zeilen über den WLAN Stick!?!? Das sieht etwas komisch aus...

Klingt danach, als sei Energiesparen als erlaubt konfiguriert. So etwas wie green mode. Sollte kein Anlass zur Beunruhigung geben.

Zitat von Kamikaze01

Ansonsten ist meine CPU und RAM Auslastung eigentlich sehr niedrig (der Ausschlag war kurzzeitig beim Login).

Wie der normale Betriebszustand ist, sollte unerheblich für die Restarts sein. Es ist die Frage, wie lange dauern Ausschläge an. Selbst eine ganze Minute unter Volllast löst noch keinen Restart aus. Aber bei 2-4 Minuten Volllast scheint es bei meinen QNAP NAS, egal welches Modell, zu solchen ungeplanten Restarts kommen, einschließlich dem TS-453Be.

Habe Überhitzung nicht getestet. Da sollte thermisches Throtteling und Lüfterdrehzahlanpassung greifen, soweit nicht anders konfiguriert. Ich gehe davon aus, dass dies sauber funktioniert, und damit keinen Restart auslöst.