(2017) The file system is not clean. It is suggested that you go to [Storage Manager] to run "Check File System".

Hätte ich sagen sollen: Der Check wurde durchgeführt, auch ein kompletter Resync des RAID. Daher hatte ich am Sonntag, einige Zeit nachdem der Resync durch war, auch einen manuellen Neustart (bewusst mit einem kompletten Herunterfahren) gewagt. Dummerweise habe ich versäumt, dann auch auf die Uhr zu schauen ...

duke-f

Könntest du mal bitte deine /etc/logs/shutdown.log hier anhängen?

Befehl cp /etc/logs/shutdown.log /share/Public/ ausführen. Dann ist die Datei über die Public-Freigabe verfügbar.

Da hätte ich sogar gleich zwei:

shutdown.log vom 28.08., damals kam ein unerwarteter Neustart. Dann gibt es die deutlich größere shutdown.log.1 vom 05.09., die aus dem regulären Herunterfahren (da musste ich des .log anhängen).

Aber ist klar: Vertraulich behandeln bitte

shutdown.log

shutdown.log.1.log

Irgendwann heute ist der aktuelle resync fertig. Dann denke ich daran, mal alle Services per /etc/initd/services.sh stop zu beenden und weiteres zu beobachten. Vielleicht ist dann ja etwas zu erkennen, was Probleme macht.

Ich würde ja liebend gerne wirklich mal das System selber komplett neu aufsetzen - aber natürlich ohne nachher alles wieder mühsam einrichten zu müssen. So z.B. die E-Mail-Ablage, Plex-Datenbank, mein SmartHome, ....

Widerspricht sich wohl leider selber irgendwie.

Wurde zwischen dem 28.08. und dem 05.09. irgendetwas installiert?

Auffällig ist, dass am 05.09. Unmengen an Transcode-Tasks hängen. Plex konnte auch nicht beendet werden.

Nein, nichts. Allerdings war Plex der Grund für das herunterfahren am 5.9. Hab später festgestellt, dass es damals tatsächlich hing.

Vielleicht ist das der Übeltäter. Hatte es jetzt mal komplett entfernt und aus den Apps neu installiert.

Transcodiert wurde gerade viel, weil einige Urlaubsvideos in 4k neu dazugekommen sind. Hätte aber eigentlich schon durch sein sollen.

EDIT:

Manchmal schießt man sich ja selber ins Knie. Heute früh wundere ich mich, dass schon wieder ein RAID-Resync läuft, obwohl ich doch gestern froh war, als das endlich durch war. Jetzt stelle ich fest, ich habe irgendwann im Laufe des Ersatzes einer defekten Platte einen Zeitplan für jede Woche Freitag 01:05 angelegt und dies vergessen. Jetzt hoffe ich, dass dieses Problem vorerst damit mal erledigt ist (sobald der aktuelle Vorgang dann durch ist).

Hatte gerade mal das neue reguläre FW-Update eingespielt. Vorher habe ich extra zuerst mittels

services.sh stop

alles beendet, habe auch alle eventuell noch laufenden Transcodierungen (ich denke, das sind die my_qmonitor-Einträge) gekillt. Tatsächlich war jetzt nach dem Neustart kein Volume hinsichtlich des Filesystems zu prüfen. Leider fängt er er aber wieder an, Speicherpool 1 mit den 6x16 TB im RAID 6 zu synchronisieren.

Die Suche geht also weiter.

Zitat von dr_mike

Dann poste doch mal den Inhalt von .force_kill_in_shutdown.log bzw. der Scripte.

Das hattest du bisher noch nicht getan.

Stimmt, entschuldige. Nach dem heutigen Neustart gab es auch keine, die letzte kommt vom letzten Neustart.

Das enthaltene Skript ist nicht schön. Es wurde mal vor Jahren auf dem Raspberry Pi erstellt und vielfach manipuliert. Dann irgendwann auf das NAS übertragen.

Kann es sein, das Sync wird durch nicht korrekt ge-unmounteten (?) Laufwerken herrührt?

Zitat von duke-f

Kann es sein, das Sync wird durch nicht korrekt ge-unmounteten (?) Laufwerken herrührt?

Jup.

Dann werde es ich nächstes mal darauf auch ein besonderes Augenmerk legen. Hab jetzt auch endlich ein Ticket beim Support geöffnet.

Jetzt bin ich wieder hier angekommen.

Mal die letzten Schritte kurz zusammengefasst:

Ich habe mein System neu aufgesetzt. Details hebe ich mir auf für einen späteren Blogbeitrag, den ich diesmal wirklich fest vorhabe. Allerdings bremst mich mein System noch aus dabei.

Aber dennoch jetzt mal hier eine Frage: Ist dieser Inhalt einer .force_kill_in_shutdown.log normal oder lässt er auf Fehler schließen?

Ich habe nämlich das Problem, dass jetzt nach fast jedem Neustart immer noch Volume0 und Volume1 einem Filesystem-Check unterzogen werden. Mittlerweile habe ich viele Anwendungen nach und nach wieder deinstalliert oder zumindest deaktiviert und komme der Ursache einfach nicht auf die Schliche. Auf meiner Suche wäre ich erst mal froh zu hören, ob sich hier etwas dazu herauslesen lässt.

Ach Ja, Volume0 ist CHACHEDEV1_DATA, Volume1 ist CHACHEDEV7_DATA.

CACHEDEV12_DATA ist ein einzelnes Laufwerk, das Daten zu Surveillance enthält und das aber auch von zwei Raspberry Pis kontinuierlich beschrieben wird. Das mach offensichtlich keine Probleme. CHACHEDEV10_DATA ist mein alternativer Public-Bereich (MyPublic genannt). Warum die drei letzten als Not unmounted Path stehen verstehe ich nicht.

Not Umount list /share/CACHEDEV10_DATA
/share/CACHEDEV12_DATA
/share/CACHEDEV1_DATA
/share/CACHEDEV2_DATA
/share/CACHEDEV3_DATA
/share/CACHEDEV4_DATA
/share/CACHEDEV7_DATA
/share/CACHEDEV8_DATA
/share/CACHEDEV9_DATA
/share/external/DEV01101_1
/share/external/DEV0201_1
/share/external/DEV0202_1
/share/external/DEV0203_1
/share/external/DEV0204_1 at Sat Nov 13 13:48:42 2021
====== Not umount path /share/CACHEDEV10_DATA ======
====== Not umount path /share/CACHEDEV12_DATA ======
====== Not umount path /share/CACHEDEV1_DATA ======

Nachdem ich in das .force_kill_in_shutdown.log gesehen habe, würde ich sagen, diese Zeilen mit"not umount..."

sind die gerade gemounteten Filesysteme.

Sieht bei mir so aus:

Not Umount list /share/CACHEDEV1_DATA
/share/external/DEV3301_1 at Mon Nov 15 09:16:55 2021
====== Not umount path /share/CACHEDEV1_DATA ======
====== Not umount path /share/external/DEV3301_1 ======

Das sind mein Datenvolumem und mein ext. USB Laufwerk.

Gruss

Naja, ich habe alles in allem 9 Volumes und 5 externe Laufwerke (2x TR-004). Mich wundert eben, warum gerade die drei am Schluss nicht "geunmounted" werden.

Hast Du dieses NAS heute um 09:16:55 neu gestartet?

Ja, FW update auf 5.0.0.1853. Wobei ich nach dem Start kein Filesysstemcheck machen musste.

Deshalb bin ich davon ausgegangen, das dies die Liste der gemounteten Filesystem zum Zeitpunkt des Shutdownbefehls ist, aber nicht die Liste von Filesystemen, die nicht unmounted werden können.

Gruss

Bei mir sieht es ähnlich aus wie bei FSC830.

Not Umount list /share/CACHEDEV1_DATA
/share/CACHEDEV2_DATA at Sun Nov 14 23:28:59 2021
====== Not umount path /share/CACHEDEV1_DATA ======
====== Not umount path /share/CACHEDEV2_DATA ======

Wobei auf /share/CACHEDEV2_DATA keine Freigaben eingerichtet sind.

Wie dieses Log zu interpretieren ist, kann nur QNAP sagen. Dein Log hier deutet aber definitiv auf Fehler beim Umount.

Ich habe ja neu initialisiert und neu eingerichtet, die alten Logs sind daher weniger aussagekräftig.

Not unmount path scheint demzufolge ok zu sein. Da dreht sich meine Frage dann um: Warum die anderen 6 Volumes nicht?