Xerxes

Do you think it's related to that? When I have a minute, I'll try to change it

Back again. Now I stopped stopped docker service and vm mananger and after that the array does not stop. So I think it has nothing to do with the services. Correct me, if I'm wrong. When I start it an stop it like 2 h later it works great. Only if I want to stop it after about a week it hat no desire. I installed the zfs master plugin to see some snapshots. This one was huge! There are like 500-700 more lines. Does this look normal? The docker storage is set to native. This was recommended to me here in the forum. The server exists only for about four month and I have about 40 dockers. The command zfs list -r cache also shows all of these entries from above. I clean my server about every two weeks and shut it down for this purpose. It's never worked before for the server to shut down without errors after a few minutes. It always freezes at the exact same point. I've already tried the usual suspects, like fuser -mv /mnt/cache lsof /mnt/cache If I boot in safe mode, I can start and stop the array normally. I haven't tried it for a period longer than a week yet. What is the best way to proceed, considering that the error only occurs after a certain amount of time? Is there anything I can do to prevent this, like stopping before the array, to see if it will work? I'm currently trying a script that prepares everything, but it's not working. I keep getting the same error. #!/bin/bash echo "Starting array shutdown script..." ### 1. Unmount all SMB (CIFS) shares mounted on this server echo "Unmounting all SMB (CIFS) shares mounted on this server..." mount | grep -i cifs | awk '{print $3}' | while read -r share; do if [ -n "$share" ]; then echo "Unmounting $share" umount "$share" # Check if unmount was successful if mountpoint -q "$share"; then echo "Failed to unmount $share. Forcing unmount..." umount -l "$share" fi fi done ### 2. Stop all Docker containers echo "Stopping all Docker containers..." docker ps -q | xargs -r docker stop ### 3. Terminate SSH sessions accessing the array echo "Terminating SSH sessions accessing the array..." # Get the PID of the current script to avoid killing itself current_pid=$$ pids=$(lsof -t /mnt/disk* /mnt/user* 2>/dev/null | grep sshd | uniq | grep -v "^${current_pid}$") if [ -n "$pids" ]; then echo "Terminating SSH sessions with PIDs: $pids" echo "$pids" | xargs -r kill else echo "No SSH sessions accessing the array found." fi ### 4. Close any open files on the array echo "Closing any open files on the array..." pids=$(lsof -t /mnt/disk* /mnt/user* 2>/dev/null | uniq | grep -v "^${current_pid}$") if [ -n "$pids" ]; then echo "Terminating processes with PIDs: $pids" echo "$pids" | xargs -r kill else echo "No processes accessing the array found." fi ### 5. Stop VMs echo "Stopping all VMs..." virsh list --name | while read -r vm; do if [ -n "$vm" ]; then echo "Shutting down VM: $vm" virsh shutdown "$vm" # Initialize countdown max_wait=150 # Maximum wait time in seconds interval=10 # Interval between checks elapsed=0 while [ $elapsed -lt $max_wait ]; do sleep $interval elapsed=$((elapsed + interval)) echo "Checking if VM '$vm' has shut down... (Elapsed: ${elapsed}s)" if ! virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' has shut down gracefully." break fi done # After timeout: force shutdown if virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' did not shut down in time. Forcing shutdown..." virsh destroy "$vm" sleep 5 if ! virsh list --name --state-running | grep -qw "^${vm}$"; then echo "VM '$vm' has been forcefully terminated." else echo "Failed to forcefully terminate VM '$vm'. Manual intervention may be required." fi fi fi done ### 6. Stop SMB services echo "Stopping SMB services..." /etc/rc.d/rc.samba stop ### 7. Stop NFS services echo "Stopping NFS services..." /etc/rc.d/rc.nfsd stop ### 8. Stop additional services (optional) echo "Stopping additional services..." # Example: /etc/rc.d/rc.plexmediaserver stop Is this a known problem with any plugin?

Konntet ihr herausfinden, was das Problem war? Stehe aktuell vor der gleichen Herausforderung. Docker und VMs in den Einstellungen deaktiviert und trotzdem beim stoppen des Arrays bleibt es immer hängen bei Mar 28 12:21:21 nasgul emhttpd: Unmounting disks... Mar 28 12:21:21 nasgul emhttpd: shcmd (157761): /usr/sbin/zpool export -f cache Mar 28 12:21:21 nasgul root: cannot export 'cache': pool is busy Mar 28 12:21:21 nasgul emhttpd: shcmd (157761): exit status: 1 Mar 28 12:21:21 nasgul emhttpd: Retry unmounting disk share(s)... Die Infos unter "lsof", "cat /proc/mounts" zeigen keinen Zugriff mehr auf den Pool an. Userscripts sind alle gestoppt. Terminals alle geschlossen. Plugins, die ich installiert habe: Appdata Backup Community Applications Custom Tab Dynamix Active Streams (zeigt keine offenen Streams an) Dynamix Cache Directories (nach einer Deinstallation auch keine Besserung) Dynamix Safe Mode Dynamix Stop Shell Dynamix System Temperature Fix Common Problems GPU Statistics Intel GPU TOP Libvirt Hotplug USB mergerFS for UNRAID (fügt ein Dateisystem des Arrays mit meinem zweiten Cache zusammen. Beim Array-Stop liefert der Skript eine "0", schon vor erster Installation des Plugins traten o.g. Probleme auf) Nvidia Driver Python 3 for UNRAID Unassigned Devices Unassigned Devices Plus unbalanced (Nicht aktiviert) Unraid Connect Unraid Patch User Script (Kein Skript läuft mehr)

Bis jetzt keine Fehler mehr, nachdem ich alle C-States im BIOS deaktiviert habe. Dass nicht trotzdem der Server dauernd alle Kerne voll benutzt habe ich die P-Cores und die Hälfte der E-Cores für die VMs reserviert und diese sind in der syslinux.cfg nun isoliert. Die VMs, die diese Kerne nutzen, haben mit den Kernen keinerlei Probleme. Ich schließe mal daraus, dass es wohl an den C-States lag. Die 14. Gen i9 mag das wohl nicht.

I only did this so that I didn't have to force a restart while stopping the array. In operation, I wouldn't just do it like that

In my case I restart emhttpd and install the „shell stop“ plugin. Since then I do not have any issues stopping the array. But thats more like symptom supression than cause control. I'm not really satisfied, but it does what it's supposed to

Soo, eine neue CPU liegt seit Tagen hier, aber die alte hat das wohl mit bekommen und seit paar Tagen kein einziger Fehler mehr. Bis auf: Habe prime95 auf windows bare metal laufen lasse. Mehrere Stunden. Im Moment des Beendens bekomme ich ein BSOF und Windows schmiert ab. Für mich war das ein Zeichen, dass der Prozessor wohl keinen "Ruhezustand" mag und habe C-States komplett im BIOS deaktiviert. Habe nun auch die syslinux.cfg wieder auf deafult zurückgesetzt, sodass cpu4 auch wieder ran darf. Auch das ist nun soweit fehlerfrei. Bis jetzt. Sobald wieder Fehler kommen, werde ich doch mal die CPU tauschen.

No. To be sure that no extern processes were suspending my server I disconneced the lan-cable and pluged in a monitor.

Did that. System log is still flooded with these errors Feb 6 17:56:59 nasgul emhttpd: Unmounting disks... Feb 6 17:56:59 nasgul emhttpd: shcmd (229694): /usr/sbin/zpool export -f cache Feb 6 17:56:59 nasgul root: cannot export 'cache': pool is busy Feb 6 17:56:59 nasgul emhttpd: shcmd (229694): exit status: 1 Feb 6 17:56:59 nasgul emhttpd: Retry unmounting disk share(s)...

And for the moment? Restart the server by a hard-reset?

At the moment docker and docker daemon is not running. docker info Client: Version: 27.0.3 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.15.1 Path: /usr/libexec/docker/cli-plugins/docker-buildx Server: ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? errors pretty printing info /etc/rc.d/rc.docker status Docker daemon is not running. How can I stop my array safely now? I don't want to perform another hard shutdown using the reset button. Before hitting the "Stop Array" button in the GUI, I manually stop all containers to make sure that no container is using the cache.

I am now having the same problem in 7.0.0 stable. Unraid is now trying for more than an hour to export my chache. Down are my full diagnostics. Output of losetup was: NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 so there are no other loops to unmount than these from unraid. output of zpool status cache was: zfs get mounted cache pool: cache state: ONLINE scan: scrub repaired 0B in 00:03:03 with 0 errors on Sat Jan 25 22:03:47 2025 config: NAME STATE READ WRITE CKSUM cache ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvme1n1p1 ONLINE 0 0 0 nvme0n1p1 ONLINE 0 0 0 errors: No known data errors NAME PROPERTY VALUE SOURCE cache mounted no - What else can I do to stop the array correctly? The error occurs with every array stop. You can ignore the corrected faults of the parity in the syslog attached. It's caused by a hard shutdown a couple of days ago. diagnostics-20250206-1226.zip

Kleines Update: RAM getauscht gegen Corsair Vengeance. Fehlercodes kamen weiterhin. Memtest, wie mit dem vorherigen RAM, unauffällig. Am kommenden Samstag wird eine "Ersatz-CPU" eingebaut für ein paar Tage. Seit dem ich isolcpus=4 als Notlösung zu der syslinux.cfg hinzugefügt habe, schaut alles stabil aus und es gibt keine Segfaults mehr. Scheint also wohl auf den ersten Blick tatsächlich ein defekter Kern zu sein. Sobald die neue (nicht) CPU funktioniert, werde ich nochmal Bescheid geben.

Tatsächlich nicht, aber: ich glaube auch, dass die Platten in Ordnung sind. Die eine Platte ist über ein SATA-Kabel, die andere über einen HBA mit einem SAS zu SATA-Kabel verbunden, deswegen würde ich die Kabel in dem Fall fast ausschließen (komplett andere Verbindungstechnik). Vor allem, da die Fehler im gleichen Moment kamen und beide Platten zu dem Zeitpunkt beschrieben wurden.

Hi, nachdem ich vor drei Tagen zwei HDDs zu meinem Array hinzugefügt hatte (beide an einem LSI 9207-8i angeschlossen), ist heute/vorhin auf einmal gleichzeitig bei zwei Platten der UDMA CRC Error Count auf "1" gewechselt. Ich habe gelesen, dass die mit hoher Wahrscheinlichkeit am Kabel oder am Controller liegt, jedoch ist eine Platte per Sata-Kabel direkt mit dem Mainboard (Intel Z790 Chip) verbunden, die andere über ein SFF-8087 Kabel mit dem LSI 9207-8i Controller. Beide Platten waren zu dem Zeitpunkt des Errors am beschreiben, also diese sind nicht gerade erst hochgedreht worden. Hängt dies mit einem höheren Problem, sprich z.B. Betriebssystem zusammen? Beide Platten, die den Error bekommen haben, waren Bestandsplatten, also nicht eine der beiden neuen. Wie kann ich das Problem elegant "ignorieren", ohne dass ich bei einer Status-Meldung über einen Messenger-Dienst nun jedes Mal eine Warnung bekomme und nicht alle paar Tage manuell den Counter überprüfen muss, falls ich den Error 199 einfach deaktiviere. Wenn ich im Dashboard die Meldung den Daumen nach unten bestätige, werden dann neue Fehler trotzdem angezeigt? Danke schonmal unraid-diagnostics-20250127-2040.zip

Ja, nächste Woche bringt ein Kollege mal seinen 11500 mit, dann werde ich den mal testen. Habe LGA1700 nicht zur Auswahl rumliegen Pins sahen aber top aus und CPU auch. Da hast du allerdings vollkommen Recht, hatte ich gar nicht bedacht. Mal geht das Netzwerk, mal nicht. SSH ist unfassbar träge. Bildschirm direkt angeschlossen zeigt nichts (schwarz) Keine Regelmäßigkeit festzustellen können. Als es wieder begonnen hatte, war der automatische email-abruf in paperless dran schuld (wieder python-fehler). Die 100x vorher und die 100x nachher hatte es jedoch wunderbar geklappt. Email war zu der Zeit keine zu verarbeiten. Die nächsten Male kamen die kernel traces unkontrolliert und wenn der erste kam, war der zweite nicht weit und das ging dann immer schneller bis zum systemabsturz. habe auch wieder meine cpu4 lesen können als „likely“.

Nachdem ich letzte Woche mal die CPU ausgebaut hatte, lief der Server nun 4 Tage mit nur einem Segfault und seit heute Abend kommen wieder sehr viele kernel traps und der server ist ständig nicht mehr erreichbar und ich muss ihn zu einem reboot per Knopf zwingen. nachdem ich die CPU ausgebaut hatte, lief prime95 für 12h ohne Probleme, memtest86 lief auch nochmal paar Stunden problemlos. wie kommen solche Fehler so sporadisch. fehlertexte habe ich natürlich keine, nach dem reboot ist ja alles weg. werde mal im nächsten Schritt meinen DNS (Raspi) als Syslog-Server einrichten. Wenn vor der „Reassemblierung“ der CPU prime95 nicht mal eine Minute lief und ich die CPU einfach nur aus- und wieder eingebaut habe, wie kann es danach problemlos laufen für 5 Tage und nun wieder die selben Faxen machen?

[Main thread Jan 18 16:00] Mersenne number primality test program version 30.19 build 20 [Main thread Jan 18 16:00] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 12x2730 KB, L3 cache size: 36 MB [Main thread Jan 18 16:00] Starting workers. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #5. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #1. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #3. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #2. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #3. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #4. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #2. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #5. [Main thread Jan 18 16:01] TORTURE TEST FAILED on worker #1. Test lief nicht mal eine Minute, bis fast alle (5 von 8 ) P-Cores gestoppt wurden... E-Cores und Core 6-8 laufen noch. Ist da eine Einstellung falsch? Habe was gelesen, dass man im BIOS irgendwas bzgl Spannung und Taktrate vom RAM und evtl. XMP anschalten sollte. Meiner Meinung soll ein System doch aber ohne manuelles Zutun wenigstens stabil laufen, oder liege ich falsch? Das ist das Ergebnis von Core 1, 2, 3, 5 [Jan 18 16:00] Worker starting [Jan 18 16:00] Beginning a continuous torture test on your computer. [Jan 18 16:00] Please read stress.txt. Choose Test/Stop to end this test. [Jan 18 16:00] Test 1 (thread 2 of 2), 76000 Lucas-Lehmer in-place iterations of M4028769 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:00] Test 1 (thread 1 of 2), 76000 Lucas-Lehmer in-place iterations of M4028769 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:01] FATAL ERROR: Final result was F176DFFE, expected: 6186CC09. [Jan 18 16:01] Hardware failure detected running 200K FFT size, consult stress.txt file. [Jan 18 16:01] FATAL ERROR: Final result was 939BDBAA, expected: 6186CC09. [Jan 18 16:01] Hardware failure detected running 200K FFT size, consult stress.txt file. [Jan 18 16:01] Torture Test completed 2 tests in 0 minutes - 2 errors, 0 warnings. [Jan 18 16:01] Worker stopped. Und das von Core 4, hier ist ja auch meine CPU 8 dabei, die mir in Unraid immer die Segfaults macht, jedoch schaut die komischerweise gut aus: [Jan 18 16:00] Worker starting [Jan 18 16:00] Beginning a continuous torture test on your computer. [Jan 18 16:00] Please read stress.txt. Choose Test/Stop to end this test. [Jan 18 16:00] Test 1 (thread 1 of 2), 76000 Lucas-Lehmer in-place iterations of M4028769 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:00] Test 1 (thread 2 of 2), 76000 Lucas-Lehmer in-place iterations of M4028769 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:01] FATAL ERROR: Final result was A99ADDF8, expected: 6186CC09. [Jan 18 16:01] Hardware failure detected running 200K FFT size, consult stress.txt file. [Jan 18 16:01] Test 2 (thread 2 of 2), 76000 Lucas-Lehmer in-place iterations of M3978767 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:01] Test 3 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3835553 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:02] Test 4 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3785551 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:03] Test 5 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3735553 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:03] Test 6 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3735551 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:04] Test 7 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3688945 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:04] Test 8 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3618943 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:05] Test 9 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3538945 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:05] Test 10 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3538943 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:06] Test 11 (thread 2 of 2), 88000 Lucas-Lehmer in-place iterations of M3342337 using FMA3 FFT length 200K, Pass1=640, Pass2=320, clm=2. [Jan 18 16:06] Self-test 200K (thread 2 of 2) passed! [Jan 18 16:06] Torture Test completed 12 tests in 5 minutes - 1 errors, 0 warnings. [Jan 18 16:06] Worker stopped. Aber ganz allgemein finde ich, das schaut nicht normal aus. Mein Ryzen 9 6900HX in meinem Laptop macht da nicht so Faxen.

Gut zu wissen. Tatsächlich ist der Chip recht neu (2 Monate) und dank Paperless, wenn es doch funktioniert, die Rechnung schnell auffindbar. CPU wurde nicht einmal übertaktet. Da das so ein Beast ist und ich die ganze Zeit noch keine Zeit zum zocken hatte, hat die warscheinlich noch nie über 10% gemacht unter Linux. Habe vorhin auch schon drüber nachgedacht, einfach nen Garantieantrag zu stellen. Aber ich sehs dann kommen und die entweder die CPU hat nix und ich muss die Überprüfung zahlen oder die macht einfach bei der Prüfung alles wunderbar mit und ich bin wieder am Anfang. Aber da der Fehler, wie eben schon geschrieben, wirklich ausschließlich auf core 8 auftritt und RAM i.O. ist, glaube ich immer mehr, dass es ein HW Problem ist. Sobald meine Parität fertig überprüft hat werde ich mal das Prime95 anschauen. Sieht man da dann auch, was genau der Fehler ist? Das Intel Tool hatte ich schon mal getestet, ist eher so määh.

Backup abgeschlossen, alles auf den Disks gelöscht, Array und Cache Pool neu formatiert, alles von Grund auf von vorne begonnen mit 7.0.0. Nur media-Ordner ist noch alt. Nach 3-4h up-time und nur Paperless mit Redis installiert kommt schon der erste Segfault, aber ohne Systemabsturz. Kann gut sein, dass das schon immer war und ich es einfach nie gesehen habe, da mein log bis vor kurzem mit aspm-Meldungen geflutet wurde. Jan 17 21:05:04 nasgul kernel: [celeryd: celer[949456]: segfault at 28 ip 000015267a4c77d8 sp 00007ffcc194eeb0 error 4 in libpython3.12.so.1.0[15267a2b8000+216000] likely on CPU 4 (core 8, socket 0) Jan 17 21:05:04 nasgul kernel: Code: 89 44 24 38 31 c0 48 89 56 38 4d 8d bc 24 c0 00 00 00 49 8b 8c 24 a8 00 00 00 4c 29 fa 48 89 d0 48 d1 f8 4c 63 f0 4b 8d 2c 36 <48> 03 69 28 83 7f 2c 00 74 27 0f b6 45 00 48 8b 54 24 38 64 48 2b Der Fehler kam genau 4s nach dem Ausführen der 5-minütigen Abfrage der Mails und in Paperless standen auch Fehler. Da dieser Fehler immer auf CPU 4 (core 8, socket 0) kommt ist das für mich naheliegend, dass die CPU was hat. Plex habe ich mich noch nicht getraut zu installieren, wollte erstmal die Daten wieder sauber zurückspielen ohne crashes. Kennt ihr gute Tools, mit denen man sowas testen kann? Also eventuell defekte Cores auf Leistung testen. Ich glaube, dass Windows hier zu weit weg von der Hardware ist.

Ich meinte Hauptsächlich im Bezug auf den atlanic Treiber im Kernel

Habe über Nacht das array gesichert auf externen Platten und es kam heute morgen einmal noch genau der gleiche Fehler. Alle docker deinstalliert und einziges Plugin war das unassigned devices. Kann das am Atlantik Treiber liegen? Also tatsächlich das 10 GbE? Evtl das neue setup mit 7.0.0 stable beginnen, da doch recht neue Hardware?

Mir ist heute das System noch ein paarmal abgestürzt, auch nachts im idle. Die verbundenen Docker liefen weiter, aber konnte einen laufenden Docker nicht neu aufrufen. Habe mich entschieden, alle unersetzbaren Daten im Array auf andere, externe Festplatten zu schieben, mit Ubuntu to go einmal alles platt und den Rest einfach neu erstellen. Ein paar Docker hab ich intern gesichert. Finde ich absehbarer als jetzt Ewigkeiten rum zu probieren. Möchte ein stabiles System, kein 50/50 Andere LAN-Schnittstelle hab ich nicht getestet. Hatte mal testweise einen anderen RAM eingebaut, immer noch Segfault Meldungen. Werde mir am Wochenende das mal vorknöpfen und fange mit paperless an und beobachte mal den log. Als ich die Sicherung gemacht habe mit sudo docker exec paperless-ngx document_export ../export -f musste ich den Befehl sicher so 10-15x ausführen, bis es ohne, jedes mal unterschiedliche, Fehler in python ging. Zu dem Zeitpunkt war nur Redis und Paperless am laufen.

Ja, nicht mal mit einer nicht aktuellen Version das erste Mal gebootet. System ist erst 2 Monate alt, da gabs das BIOS schon. Unterstützt auch den 14900K. Overclocking ist aber aus und er taktet mit 3.2GHz, also ganz gemütlich. Ist seit Tag 1 deaktiviert. Genauso der 2,5GbE Port. Nutze nur das 10 GbE per LAN. Ist ein Marvell-Aqtion Adapter. Könnte auch den Intel (2,5GbE) aktivieren und mal probeweise nehmen. hab tatsächlich noch eine Intel X550-T2 rumliegen. Würde das mit den Segfaults zusammenpassen? Wobei ich in diesem Log keine gefunden habe Aber mal nebenbei: sollte der Fehler dann nicht schon seit Tag 1 kommen? Mir ist noch nie das System eingefroren oder abgestürzt. Eben kamen noch, ohne eine Änderung meinerseits, folgende Meldungen, was im Bezug auf das Netzwerk interessant sein könnten. Jan 15 20:38:42 nasgul kernel: atlantic 0000:06:00.0 eth0: atlantic: link change old 10000 new 0 Jan 15 20:38:42 nasgul kernel: bond0: (slave eth0): link status definitely down, disabling slave Jan 15 20:38:42 nasgul kernel: device eth0 left promiscuous mode Jan 15 20:38:42 nasgul kernel: bond0: now running without any active interface! Jan 15 20:38:42 nasgul kernel: br0: port 1(bond0) entered disabled state Jan 15 20:38:43 nasgul dhcpcd[1742]: br0: carrier lost Jan 15 20:38:43 nasgul dhcpcd[1742]: br0: deleting route to 10.0.0.0/16 Jan 15 20:38:43 nasgul avahi-daemon[13021]: Withdrawing address record for 10.0.2.1 on br0. Jan 15 20:38:43 nasgul avahi-daemon[13021]: Leaving mDNS multicast group on interface br0.IPv4 with address 10.0.2.1. Jan 15 20:38:43 nasgul avahi-daemon[13021]: Interface br0.IPv4 no longer relevant for mDNS. Jan 15 20:38:43 nasgul dhcpcd[1742]: br0: deleting default route via 10.0.0.1 Jan 15 20:38:45 nasgul ntpd[24025]: Deleting interface #1 br0, 10.0.2.1#123, interface stats: received=19, sent=19, dropped=0, active_time=900 secs Jan 15 20:38:45 nasgul ntpd[24025]: 216.239.35.4 local addr 10.0.2.1 -> <null> Jan 15 20:38:47 nasgul kernel: atlantic 0000:06:00.0 eth0: atlantic: link change old 0 new 10000 Jan 15 20:38:47 nasgul dhcpcd[1742]: br0: carrier acquired Jan 15 20:38:47 nasgul kernel: bond0: (slave eth0): link status definitely up, 10000 Mbps full duplex Jan 15 20:38:47 nasgul kernel: bond0: (slave eth0): making interface the new active one Jan 15 20:38:47 nasgul kernel: device eth0 entered promiscuous mode Jan 15 20:38:47 nasgul kernel: bond0: active interface up! Jan 15 20:38:47 nasgul kernel: br0: port 1(bond0) entered blocking state Jan 15 20:38:47 nasgul kernel: br0: port 1(bond0) entered forwarding state Jan 15 20:38:47 nasgul dhcpcd[1742]: br0: rebinding lease of 10.0.2.1 Jan 15 20:38:47 nasgul dhcpcd[1742]: br0: probing address 10.0.2.1/16 Jan 15 20:38:51 nasgul dhcpcd[1742]: br0: leased 10.0.2.1 for infinity Jan 15 20:38:51 nasgul avahi-daemon[13021]: Joining mDNS multicast group on interface br0.IPv4 with address 10.0.2.1. Jan 15 20:38:51 nasgul avahi-daemon[13021]: New relevant interface br0.IPv4 for mDNS. Jan 15 20:38:51 nasgul avahi-daemon[13021]: Registering new address record for 10.0.2.1 on br0.IPv4. Jan 15 20:38:51 nasgul dhcpcd[1742]: br0: adding route to 10.0.0.0/16 Jan 15 20:38:51 nasgul dhcpcd[1742]: br0: adding default route via 10.0.0.1 Jan 15 20:38:51 nasgul network: hook services: interface=br0, reason=BOUND, protocol=dhcp Jan 15 20:38:51 nasgul network: update services: 45s Jan 15 20:38:54 nasgul ntpd[24025]: Listen normally on 2 br0 10.0.2.1:123 Jan 15 20:38:54 nasgul ntpd[24025]: new interface(s) found: waking up resolver

Habe ich gemacht. 5 Minuten später hat sich das System wieder aufgehängt. Das maximale, was ich hin bekommen habe, ist der log aus dem Webterminal, da GUI nicht reagiert. Vielleicht hilft das. Die rot markierten Stellen im log sind Jan 15 19:59:22 nasgul kernel: Call Trace: Jan 15 19:59:22 nasgul kernel: CPU: 8 PID: 17145 Comm: Plex Media Scan Tainted: P D O 6.1.118-Unraid #1 Jan 15 19:59:22 nasgul kernel: Call Trace: Jan 15 19:59:44 nasgul kernel: CPU: 8 PID: 17145 Comm: Plex Media Scan Tainted: P D O 6.1.118-Unraid #1 Jan 15 19:59:44 nasgul kernel: Call Trace: Jan 15 19:59:44 nasgul kernel: CPU: 29 PID: 26936 Comm: Plex Media Scan Tainted: P D O 6.1.118-Unraid #1 Jan 15 19:59:44 nasgul kernel: Call Trace: Jan 15 20:01:50 nasgul kernel: Call Trace: Jan 15 20:01:50 nasgul kernel: CPU: 18 PID: 15 Comm: rcu_preempt Tainted: P D O 6.1.118-Unraid #1 Jan 15 20:01:50 nasgul kernel: Call Trace: Jan 15 20:01:50 nasgul kernel: device offline error, dev sde, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 2 mehr konnte ich nicht retten. Was zu dem Zeitpunkt /dev/sde war, kann ich nicht sagen. Irgendwie kommt es mir vor, als wenn der Fehler von Paperless zu Plex übergegangen ist... Ist auch weg. Stick ist neu aufgesetzt, config übernommen. go-file wieder auf Standard, python.plg ist runter. Musste das System eben wieder killen per Ausknopf. 0,0 Reaktion mehr. Tut jedes mal weh unraid log 20250115-2009.txt