Xerxes

Danke schonmal für diese Mühen! # Setting environment of docker sysctl -w vm.overcommit_memory=1 Das habe ich geschrieben, dass Redis nicht mehr pienst, da in den Redis logs diese Meldung (man solle den Parameter auf 1 Setzen) als Warnung steht. Hatte gehofft, dass sich Paperless gewissenhafter mit Redis verbinden kann. Vergeblich. Trotzdem ist die Warnung weg. Ich schätze mal bei 128GB RAM sollte das keine Probleme bereiten. lrwxrwxrwx 1 root root 33 Jan 15 11:14 dwpython.plg -> /boot/config/plugins/dwpython.plg Das Python Plugin hatte ich auch nur zum testen installiert, ist aktuell wieder entfernt. Plex an sich läuft eigenständig. Es ist nur die Beobachtungsliste per RSS-Feed mit Sonarr/Radarr/Lidarr verbunden. Sonst keine Verbindung, keinerlei user-scripts. Meinst du, ich soll alle Daten im Cache neu erstellen? Ist enorm viel Arbeit. Da steht auch was von celeryd, also hatte ich hier angesetzt und eben die Warnung mit sysctl -w vm.overcommit_memory=1 versucht zu beheben.

Die Sicherung beinhaltete mnt/appdata, mnt/domains und mnt/system/libvirt. Dateien, die ich nicht erneut erstellen wollte. Die Container habe ich nach dem zurückspielen der appdata alle neu installiert. Oder was genau meinst du mit Muss nicht zfs sein. Muss auch nicht RAID1 sein. Aber da ich keine Erfahrungen hiermit habe und mir empfohlen wurde von btrfs weg zu gehen, bin ich eben auf zfs gewechselt.

Mein System hat sich jetzt seit heute Mittag 3x aufgehängt und es half nur ein hard reset. Ssh, WEBGui, geöffnete Docker, Web-Terminal, Web-Log, alles eingefroren. Nach ein paar Minuten kam "Internal Server Error 500" auf dem Browser. Bildschirm angesteckt, keine Ausgabe der Konsole. "Ins blaue" mal angemeldet und reboot getippt, nichts passiert. Logs hab ich leider keine davon, da ja nur ab boot gespeichert wird. Ab dem ersten Hängen hatte ich parallel den Live-Log offen, um vielleicht noch die letzte Meldung vor Crash zu bekommen. Erfolglos. Nur Statusmeldungen von irgendwelchen Plugins. Mache im Moment einen Segmenttest meines Boot-Sticks, sieht nach den ersten beiden Durchgängen noch gut aus. Wenn ich parallel boote über die NVMe auf Windows funktioniert Windows laut Ereignisanzeige auch problemlos, also wird wohl irgendwas Unraid-Spezifisches sein. Das System hat sich alle dreimal aufgehängt, als ich Filme von Radarr umbenennen hab lassen. Nach dem neu booten war die Datei jedoch noch nicht umbenannt. Rechte des Film-Ordners und die Ordner darunter sind -rwxrwxrwx und Besitzer ist "root", falls diese Info hilft. Kann das Problem beim Kernel liegen und ich sollte es nochmal mit den zfs-Pools mit 7.0.0 versuchen? Bin echt Ratlos und hab schon ein bisschen Hass auf das System... Da der Fehler doch sehr sporadisch kommt, hab ich keine Ahnung wo ich anfangen soll.

Cache gesichert (außer /system/docker), neu als zfs raid1 formatiert, Docker-image als xfs.img eingestellt, alle Daten zurückgespielt und die Docker neu hinzugefügt. Ist es normal, dass ich beim Sichern des Cache auf eine externe SSD eine Schreibgeschwindigkeit von ca. 400MB/s habe und beim zurückspielen der Daten nur noch 200MB/s? Ist der overhead bei zfs so arg? Das Gute: Pools sind nun so 5°C kälter. Das Schlechte: Nun kommen andere Docker mit Segfaults in der libpython (zb Plex) und stürzen ab. Außerdem startet nun paperless erst beim 4-7 Anlauf. Sonst stürzt es direkt nach dem Start ab und im log steht wieder "segfault...libpython..." oder "ld-linux-x86-64.so.2". Habe nochmal python 3 installiert, keine Abhilfe In der Übersicht kam nun ein neues Symbol dazu, das seit der Formatierung des Pools auf 100% steht Gehört das so? Beim Hover darüber steht 3.15 GiB Anbei nochmal ein aktueller Log von eben mit den letzten "segfault "Meldungen diagnostics-20250115-1233.zip

Paperless läuft nicht im privileged mode. Ich hatte mal spaßeshalber python 3 installiert, um wegen den Bibliotheksfehlern zu schauen, ob die dann weg gehen. Hatte nichts geändert. Die Kernel Fehler bzgl. btrfs hatte ich im ersten Schritt mal ignoriert und gehofft, dass das keinen Zusammenhang hat. Was schafft da Abhilfe? Cache anders formatieren? Geht das überhaupt? Bzgl. des Docker-Setups "Verzeichnis": Ich hatte mir zur ersten Einrichtung von Unraid das Video von TheGeekFreaks auf YT angeschaut, und der Alex hat das empfohlen (Falls das img sich zerschießt, sind nicht gleich alle Docker kaputt). Habe ich ohne Fragen übernommen, hat für mich Sinn ergeben. Soll ich das besser auf btrfs-/ xfs-Verzeichnis stellen? Scrub schuf keine Abhilfe. Werde ich später nach der Arbeit mal machen. Cache dann aber mit btrfs formatieren? Hier werde ich nicht ganz schlau, was genau du meinst. Aber ganz allgemein meinst du, dass das eher ein Software- statt eines Hardware-Fehlers ist?

Hallo, seit kurzem habe ich das Problem, dass ich viele "Segfault"-Fehler im Log habe und teilweise deswegen meine Container abstürzen. Es kommt gefühlt immer öfter vor. Ich kann nicht sagen, wie lange der Fehler schon im Log steht, aber meine Container stürzen erst seit ein paar Tagen ab. Was ich bereits gemacht habe: Memtest, auch mit einzeln gestecken RAMs -> min. je 4 Durchgänge -> Pass System mit nur einem RAM gestartet -> Fehler kommt auch Boot-Stick neu aufgesetzt (config kopiert von vor der Neuinstallation) -> Keine Änderung CPU-Test (Intel Processor Diagnostics Tool) (Auf einer Win-Installation auf einer NVMe ohne VM) -> Pass Cinebench 30 Min Single Core Test -> keine Auffälligkeiten Fehlerbeschreibung: Der Fehler tritt hauptsächlich (quasi nur) auf, wenn paperless-ngx Dokumente verarbeitet. Das Komische: Kein Update von irgendwas gemacht, was den Kernel-Fehler verursachen könnte. Wenn ich ein Dokument (irgend ein pdf) hochlade, kommt sporadisch der Fehler und das pdf kann nicht verarbeitet werden. Wenn ich es dann nochmal hochlade, geht es zu 70%. Wenn nicht, beim dritten Mal. Außerdem stürzt auch gerne der "Umlautadaptarr" mit einem dotnet-Fehler ab. Andere Container scheinen stabil. Hardware: CPU: Intel Core i9 14900K (kein overclocking!) MB: Asus Proart Z790 Creator Wifi RAM: 4x 32GB Crucial Pro GPU: Nvidia 4070ti super (Passtrhrought VM) Storage: 2x WD Black 770 1 TB for Cache (Raid1) Storage VM: 1x WD Black 7701 TB , 1x WD Black 770 2 TB (Passthrought VM) Main-Storage: 3x Seagate Ironwolf Pro 20TB Software: Unraid 6.10.14, error kommt auch in 7.0.0 Anbei mein syslog von 7.0.0 und 6.10.14. Im log von 6.10.14 ist es am Schluss des logs sehr deutlich zu erkennen, was ich meine. Hier habe ich noch meinen Reddit-Beitrag, in dem ich noch die alten Fehlercodes angehängt habe. Außerdem sind hier die Fehlercodes in vom paperless log. Hier ein kleiner Einblick: Jan 12 17:50:50 nasgul kernel: gunicorn: worke[403374]: segfault at 0 ip 0000152757318d07 sp 0000152754296950 error 4 in libpython3.12.so.1.0[1527572fe000+215000] likely on CPU 4 (core 8, socket 0) Jan 12 20:22:03 nasgul kernel: python3[1107071]: segfault at 28 ip 0000152cb9b0cc38 sp 00007ffea28e5f60 error 4 in libpython3.12.so.1.0[152cb98fe000+215000] likely on CPU 4 (core 8, socket 0) Jan 12 20:23:59 nasgul kernel: [celeryd: celer[1115918]: segfault at 28 ip 0000145ab730cc38 sp 00007ffe77d20d60 error 4 in libpython3.12.so.1.0[145ab70fe000+215000] likely on CPU 4 (core 8, socket 0) Jan 12 20:39:16 nasgul kernel: tesseract[1189108]: segfault at 4135999a ip 0000152afba614de sp 00007fff60247b30 error 4 in libtesseract.so.5.0.3[152afb886000+225000] likely on CPU 4 (core 8, socket 0) Ich habe keine Ahnung, wie ich als nächstes vorgehen soll, was ich testen kann, ob ich bei der Hardware (Immer Core 8 im log) oder bei der Software suchen soll. System ist ca. 2 Monate alt. syslog 7.0.0.zip syslog 6.10.14.zip