QNAP stürzt unregelmäßig ab

Firmware nochmal manuell drüberinstallieren?

Hallo Obi Wahn,

konntest du die Probleme auf den HDD-Fehler zurückführen oder bestehen deine Probleme trotzdem weiter?

Falls kein HDD-Problem:

Hast du irgendwas mit Java (JDownloader?) als Basis am laufen? Bzw. eine Java-App (QJDK8?) installiert?

Bei mir (TS-653D, 20GB RAM, Firmware sowohl 4.x als auch 5.x ausprobiert) gab es da auch Probleme, nach spätestens 1 Tag hat sich das System verabschiedet (entweder durch nicht-reagieren bzw. Web-Oberfläche nicht mehr erreichbar obwohl noch per Ping eine Antwort kam oder durch spontanen Neustart).

Die Logs waren hier auch nicht hilfreich, da hier kein Grund des Neustarts erfasst wurde, nur eine wenig hilfreiche Meldung über "unkontrolliertes Herunterfahren" beim nächsten Start.

Symptom war u.a. dass sich der verfügbare Speicher regelmäßig auf <2% reduziert hat (Verursacher des Speicherverbrauchs habe ich über den Ressourcenmonitor auch nicht identifizieren können).

Erste Lösung war: über Nacht ausschalten, morgens einschalten (automatisch, über Energiepläne) + regelmäßig über Qboost den Speicher freiräumen. Auf Dauer aber nicht praktikabel.

Schließlich kam bei einer Meldung "... nicht genug Speicher ... Java ..." (habe ich auch nur 1x gesehen, da hat sich die Kiste nach einigen Stunden nicht-reagieren anscheinend wieder gefangen).

Aufgrund dessen JDownloader bzw. QJDK (hier mehrere Versionen ausprobiert) neu installiert - kein Erfolg.

Aktuelle Lösung (für mein Problem):

QJDK deinstalliert, JDownloader in einem Docker-Container (über Container-Station, mit Speicher-Begrenzung auf aktuell 1GB) am Laufen. Funktioniert anscheinend bisher ohne weitere Probleme.

Habe dann noch eine Meldung bei Java in den Release-Notes über einen Memory-Leak gefunden (einfach mal nach JDK-8305517 suchen):

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Oracle Release Notes JDK 11.0.21: Bug Fixes

12

JDK-8305517

core-libs/java.net

Memory leak in Java Solaris native code when calling NetworkInterface.getHardwareAddress()

Keine Ahnung, ob dies nur auf Solaris zutrifft oder genereller Natur ist, könnte aber zumindest die Probleme bei mir erklären.

Sorry falls meine Antwort technisch nicht qualifiziert genug ist, aber ich bin noch ein NAS-Noob, der sich irgendwie versucht durchzuwurschteln...

Dafür hast du das aber schon ganz gut analysiert und ich denke du hast hier ins schwarze getroffen.

Die Contis laufen bei mir über Wochen mit Java stabil, doch die bringen halt auch ihr eigenes mit.

Hallo Leute,

Ich hatte offenbar in der Nacht auf Montag (26.02.2024) auch einen Absturz auf Raten bei meinem TVS-672X (FW 5.1.5.2645 build 20240116 vom 2024-01-25).

Auf Raten darum, weil

- nach Mitternacht nichts mehr im Log protokolliert wurde

- das Backup um 02:30 nicht durchgeführt wurde

- Snapshots nicht mehr durchgeführt wurden

- irgendwann ab 05:00 auch keine SNMP Abfragen mehr beantwortet wurden

- als ich um ~19:00 mich verbinden wollte das nicht mehr möglich war und dann auch keine Pings mehr beantwortet wurden (das dürfe bis dahin der Fall gewesen sein)

Als ich mir das Gerät dann angesehen habe, hat selbst das LCD Display nichts mehr angezeigt.

Lange auf den Ein-/Ausschaltknopf zu drücken hat das Teil dann abgewürgt (~19:25), ein Neustart hat dann zu einem Raid-Resync (WD Red pro's, ~3 Jahre alt, Raid 6, 1 Hot Spare) geführt, der kurz vor Mitternacht fertig war.

Eigentlich hatte ich für die Zeit danach einen Filesystemcheck eingetaktet und für die Zeit nach dem Backup ein Raid-Scrubbing um sicherzustellen, dass wieder ein sauberer Zustand vorherrscht.

Diese Plattenausfallsvorhersage habe ich dann deaktiviert.

Interessanterweise hat das Teil aber nach dem Raid-Resync einen Raid Rebuild durchgeführt - wodurch der Filesystemcheck nicht ausgeführt wurde.

Das Backup und neue Snapshots wurden aber erfolgreich angelegt, das Raid-Scrubbing lief um 3.30 ebenso.

Ich habe dann am Dienstag, als ich dieses Vorgänge festgestellt habe, den Filesystemcheck ohne Probleme nachgezogen, allerdings hat sich das Hot-spare von Slot 6 auf Slot 5 verändert - also irgendetwas ist da schon geschehen.

Um potentielle FW-Zusammenhänge auszuschließen, habe ich dann auch auf die neue FW (5.1.5.2679 build 20240219 vom 2024-02-26) aktualisiert - Probleme waren keine zu erkennen.

Alle Disks wurden als OK angezeigt.

Nachdem mir das Verhalten aber keine Ruhe gelassen hat, in dem Standard-Eventlog aber nichts zu sehen war, habe ich mir einen Export der Logs, den die Helpdesk-App erzeugt angesehen und bin im kmsg bzw dem offenbar vorherigen gezippten kmsg auf etliche interessante Einträge gestoßen:

2024-02-26 02:01:10 +01:00 <3> [2480309.976320] sd 1:0:0:0: rejecting I/O to offline device
2024-02-26 02:01:10 +01:00 <3> [2480309.976522] blk_update_request: I/O error, dev sdb, sector 3889510640 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
2024-02-26 02:01:10 +01:00 <3> [2480309.981781] blk_update_request: I/O error, dev sdb, sector 1060256 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

...

2024-02-26 02:01:10 +01:00 <2> [2480310.003331] md/raid1:md9: Disk failure on sdb1, disabling device.

...

2024-02-26 02:01:11 +01:00 <5> [2480310.120773] sd 1:0:0:0: [sdb] Stopping disk
2024-02-26 02:01:11 +01:00 <6> [2480310.120947] sd 1:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK

...

2024-02-26 02:01:11 +01:00 <6> [2480310.147090] md/raid1:md13: redirecting sector 908000 to other mirror: sde4
2024-02-26 02:01:18 +01:00 <6> [2480317.297026] usb 2-2: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
2024-02-26 02:01:38 +01:00 <0> [2480337.338751] watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [md1_raid6:6585]
2024-02-26 02:01:38 +01:00 <4> [2480337.346130] Modules linked in: rfcomm usdm_drv(O) intel_qat(O) uio iscsi_tcp(O) libiscsi_tcp(O) libiscsi(O) scsi_transport_iscsi(O) fbdisk(O) cfg80211 dummy br_netfilter bridge stp bonding xt_connmark xt_TCPMSS xt_LOG xt_set ip_set_hash_netiface ip_set_hash_net ip_set xt_MASQUERADE xt_REDIRECT iptable_nat nf_nat xt_policy xt_mark 8021q ipv6 uvcvideo videobuf2_v4l2 videobuf2_vmalloc videobuf2_memops videobuf2_common snd_usb_caiaq snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_rawmidi fnotify(O) nfsd nfsd_qlog udf isofs iTCO_wdt vfio_pci irqbypass vfio_virqfd vfio dm_cache_smq dm_cache exfat ufsd(PO) jnl(O) cdc_acm pl2303 usbserial qm2_i2c(O) i2c_imc(O) intel_ips drbd lru_cache flashcache(O) dm_tier_hro_algo dm_thin_pool dm_bio_prison dm_persistent_data hal_netlink(O) apex(C) gasket(C) atlantic(O) r8152(O) usbnet mii igb e1000e mv14xx(O) mpt3sas(O) scsi_transport_sas raid_class qla2xxx scsi_transport_fc k10temp coretemp uas usb_storage xhci_pci xhci_hcd usblp uhci_hcd ehci_pci e

...

2024-02-26 19:25:00 +01:00 <2> [  117.975363] md/raid1:md9: Disk failure on sda1, disabling device.
...

2024-02-26 23:01:45 +01:00 <6> [13310.369582] md: md1: requested-resync done.
2024-02-26 23:01:45 +01:00 <6> [13310.373768] md: Resyncing done: md1

Was ich als relevant erachtet habe, waren die Disk failure Einträge. Nachdem in den Exports auch folgende Info steht:

/sbin/qcli_storage -d 
Enclosure  Port  Sys_Name          Type      Size      Alias             Signature   Partitions  Model  
NAS_HOST   1     /dev/sde          HDD:data  1.82 TB   3.5" SATA HDD 1   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
NAS_HOST   2     /dev/sdd          HDD:data  1.82 TB   3.5" SATA HDD 2   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
NAS_HOST   3     /dev/sdc          HDD:data  1.82 TB   3.5" SATA HDD 3   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
NAS_HOST   4     /dev/sdf          HDD:data  1.82 TB   3.5" SATA HDD 4   QNAP FLEX   5           WDC WD2002FFSX-68PF8N0
NAS_HOST   5     /dev/sdb          HDD:spare 1.82 TB   3.5" SATA HDD 5   -- FLEX     5           WDC WD2002FFSX-68PF8N0
NAS_HOST   6     /dev/sda          HDD:data  1.82 TB   3.5" SATA HDD 6   QNAP        5           WDC WD2002FFSX-68PF8N0
NAS_HOST   7     /dev/nvme0n1      SSD:cache 476.94 GB M.2 PCIe SSD 1    QNAP FLEX   5           Samsung SSD 970 PRO 512GB
NAS_HOST   8     /dev/nvme1n1      SSD:cache 476.94 GB M.2 PCIe SSD 2    QNAP FLEX   5           Samsung SSD 970 PRO 512GB

Habe ich Dienstag Abends zuerst das Laufwerk im Slot 5 ersetzt (sdb, also neues Hot-Spare) und im Anschluss das im Slot 6 (sda).

Raid Rebuild lief gut durch, auch sonst konnte ich bisher keine Fehler feststellen.

Was mich aber massiv irritiert ist, dass bei einem Ausfall einer Platte doch bitte

- eine entsprechende Meldung im Eventlog zu finden sein sollte

- ein Raid 6 mit Hot-Spare zwar temporär degraded sein wird, aber sonst wohl eher unbeeindruckt sein sollte

- im Anschluss an die ganze Übung bitte doch nicht alle Platten als OK klassifiziert sein sollten

- folgender Eintrag im kmsg doch schräg aussieht (kam im übrigen mehrfach vor):

2024-02-26 02:01:38 +01:00 <0> [2480337.338751] watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [md1_raid6:6585]

oder sehe ich das falsch?

Ach ja - die Platte SDB habe ich im Anschluss am PC (USB) mit diskpart clean all gelöscht - ohne irgendwelche Probleme.

Wie seht Ihr das?

Vielen lieben Dank für eure Meinung!

Das können durch den CPU Lock auch Meldungen sein die von einem Software Bug ausgelöst wurden.

Die HD am PC mal auf SMART Werte prüfen und mit dem WD Tool, sollte hier Klarheit schaffen ob die wirklich ein Problem hat.

Ist halt ein Software Raid im NAS und wenn die CPU dann Mist macht, kann das als HD Fehler interpretiert werden.

Da ein CPU Lock mit einem fehlenden Pointer im Programmablauf zusammen hängen kann, ist ein Zusammenhang mit der Firmware Version zu vermuten.

Aber scheinbar gibt es hier einen Watchdoc der den Prozess dann gekillt hat. Gab auch schon Fälle wo durch so einen Fehler nach und nach alle CPU Cores locked worden sind, dann geht nix mehr.

Was ja Stunde. später dann auch wirklich bei dir passiert ist, hier half ja nur noch abwürgen.

Da hier nur wenige diesen Drive Analyser mit KI Basis verwenden, kann er sogar ursächlich sein. Jetzt hast du aber die Firmware Version geändert und ihn abgeschaltet, damit 2 Parameter geändert.

Zitat von Crazyhorse

Das können durch den CPU Lock auch Meldungen sein die von einem Software Bug ausgelöst wurden.

Die HD am PC mal auf SMART Werte prüfen und mit dem WD Tool, sollte hier Klarheit schaffen ob die wirklich ein Problem hat.

Danke für den Hinweis, das werde ich gerne machen...

Zitat von Crazyhorse

Da hier nur wenige diesen Drive Analyser mit KI Basis verwenden, kann er sogar ursächlich sein. Jetzt hast du aber die Firmware Version geändert und ihn abgeschaltet, damit 2 Parameter geändert.

Ich hätte diesen Drive Analyzer selbst wahrscheinlich gar nicht aktiviert, ich vermute, dass das einfach mit der Verfügbarkeit automatisch geschehen ist.

Prinzipiell bin ich kein besonderer Fan davon, wenn so Dinger glauben intelligent sein zu müssen - da bin ich doch eher skeptisch.. und gerade bei einem Raid6 + Hotspare sollte genug Redundanz vorhanden sein um den wirklichen Ausfall einer HDD mal für ein wenig zu überstehen.

Wegen der 2 Parameter - ja, zum Fehler identifizieren war das sicher nicht die schlaueste Vorgangsweise - allerdings muss ich gestehen, dass wenn das Thema jetzt erledigt ist, liegt mir das fast mehr am Herzen... besonders erpicht bin ich auf einen neuen Absturz nicht wirklich...

Zitat von eyetap

Drive Analyzer ..., ich vermute, dass das einfach mit der Verfügbarkeit automatisch geschehen ist.

Ist doch kostenpflichtig.

Plans & Pricing | DA Drive Analyzer | QNAP

Zitat von Becker2020

Ist doch kostenpflichtig.

Mag sein, dass ich mich nicht korrekt ausgedrückt habe - das hier war eingeschalten:

pasted-from-clipboard.png

Zitat von Crazyhorse

Was ja Stunde. später dann auch wirklich bei dir passiert ist, hier half ja nur noch abwürgen.

Was mir trotz allem noch durch den Kopf geht ist, dass ja auch nach dem Abwürgen, Neustart und zu erwartendem Raid Resync im Anschluss noch ein Raid Rebuild stattgefunden hat, welches scheinbar die existierende Hot-Spare HDD in Anspruch genommen hat - aber nachher noch immer alle Platten auf Status OK waren - UND noch immer eine, wenn auch andere, Hot-Spare vorhanden war...

Wenn ein Rebuild stattfindet, und keine HDD entfernt wurde, hätte ich mir doch erwartet, dass eine HDD als defekt aufscheint...

Sehe ich das falsch?

Nein vollkommen korrekt.

Schon mal bei allen HDs den Oberflächentest gestartet?

Ich habe ja die 2 HDD's die im KMSG mit einem Disk Failure in Verbindung gebracht wurden ausgetauscht - die werde ich wohl extern testen,

den Badblock-Test der restlichen HDD's habe ich jetzt mal begonnen.. mal sehen wie lange das dauert...

Weder der Oberflächen-/Badblocktest der im NAS aktiven HDD's, noch der intensive Test des WD Dashboardtools der ausgetauschten HDD's hat auch nur irgendeinen Hinweis auf ein tatsächliches Problem geliefert.

Ich kann mir das Verhalten nur noch mit einem Firmwarethema im Zusammenhang mit dieser "Vorhersehbaren Migration" erklären...

Drive_6_SDB_3.JPGDrive_5_SDB_3.JPGDrive_5_SDB.JPGDrive_6_SDB.JPG