Hallo zusammen,

ich habe ein Problem. Mein Server ist, für mich urplötzlich, instabil geworden. Er stürzt aktuell mindestens einmal täglich ab. Erst dachte ich, dass da Global C-States irgendwie rein spielen, aber es passierte heute Nacht zum Beispiel während eine Festplatte im PreClear war, und vorgestern während des Parity Check auf Grund des Absturzes am Tag davor.
Ich habe keine neuen Docker oder Plugins. Mit ist vor zwei Wochen ein Absturz aufgefallen. Da zeitgleich (mitten in der Nacht) die Fritzbox neustartete, bin ich von einem kurzen Stromausfall ausgegangen. Parity Check war fehlerfrei. Letzte Woche Freitag ist er aus mir unbekanntem Grund abgestürzt. Das habe ich genutzt, um den Server umzuziehen in ein anderes Gehäuse (das Jonsbo N4 ist zwar schick, aber thermisch eine Katastrophe!) inkl. Mainboardtausch. Da das Asus ROG Strix X570-E nur USB 3.x Anschlüsse hat, womit Unraid nicht vom Stick starten wollte, habe ich den Stick per Front USB angeschlossen und dann in Unraid auf eine interne SSD als Bootmedium gesetzt.

Leider ist der Server seit Sonntag jeden Tag abgestürzt. Im Log finde ich keine Einträge, die irgendwas andeuten. Da es schon vorm Mainboardtausch zwei Abstürze gab, würde ich das neue Mainboard zumindest als Hardware defekt ausschließen. Ich habe MEMTEST86+ durchlaufen lassen, da gab es keinen Fehler. Die Grafikkarte kann ich mit KI quälen, da passiert auch nichts. Es könnte, wenn Hardware, dann nur die CPU sein. Da überlege ich gerade, wie ich die am besten dauerhaft unter Last setze, um das zu prüfen.

Im Bios sind ResizeBar und SVM aktiv, der Speicher läuft ohne XMP Profile im Standardtakt. Global C States sind disabled... Was kann es noch sein? Das Bios ist mit Absicht auf einer etwas älteren Version, da dies als das stabilste in der COmmunity gilt. Dies wäre sonst mein nächster Punkt auf das neueste upzugraden.
Habt ihr noch Ideen? Könnte ich noch eine Einstellung im Bios übersehen haben? Ich habe hier meine Diagnostics angehangen. Braucht ihr weitere Infos?

Edit: Ich habe Gemini meine Diagnostics analysieren lassen. Da gibt es die Empfehlung, dass ich von macvaln auf ipvlan umstellen soll. Aber ich nutze macvlan dank der Friotzbox Problematik von unraid 6 entsprechend schon ein paar Jahre. Das sehe ich nicht als Problem an, sonst hätte ich ja in den letzten Jahren mehr Probleme haben müssen...

tower-diagnostics-20260917-0737.zip

Edited September 17Sep 17 by BastiKA84

Nimm Prime95 für den CPU Belastungstest. Gibt es auch für Linux.

Der zeigt dir auch an, wenn ein Kern defekt ist. Die längste Laufzeit um festzustellen, ob die CPU defekt war, ist 5 Stunden bei einem Kunden PC bei uns gewesen. Das hatte da tatsächlich so lange gedauert bis der Fehler auftrat. Aber wenn er auftritt, weißt du auch, dass die CPU definitiv DEFEKT ist.

Am meisten sind bei uns die 13. und 14. Generation Intel CPUs gestorben. Die hatten halt das Problem, dass die zu viel Spannung bekamen. Aber auch Ryzen CPUs sterben hin und wieder mal. Das hält sich im großen und Ganzen die Waage.

Edited September 17Sep 17 by TheGCat

Danke für die Antwort (irgendwie kann ich kein "Like" da lassen... 🤷‍♂️). Du meinst dann wahrscheinlich mit einem Linux Live USB Stick, richtig? Ich wüsste nicht, wie ich Prime95 unter unraid installiert bekomme 🙂 Ich habe heute morgen erstmal auf das neueste BIOS geupdatet. Ich hoffe, ich habe alle BIOS Einstellungen gefunden. Ist schon brutal, was dieses Board alles an Optionen bietet...
Jetzt beobachte ich den Server. Wenn der übers WOchenende wieder abstürzt oder einfriert, dann lasse ich Prime95 für ein paar Stunden laufen. Einen aktuellen ubuntu USB Stick habe ich sogar noch liegen 😃

Edit: Ach ja, ist ein Ryzen 9 5900X. Also eigentlich eine zuverlässige CPU.

Edited September 18Sep 18 by BastiKA84

Ja, zum Beispiel. Irgendein Live-Linux-System auf den Stick machen, davon booten und dann den Test mit Prime machen. Man muss ja auch nicht alles in der Unraid Umgebung testen Außerdem ist ja noch gar nicht geklärt, ob es wirklich ein CPU Problem ist. Wenn du Pech hast liegt es an Unraid oder irgendeiner Konfiguration.

PS: Vielleicht dürfen GrumpyCats keine Likes bekommen

Edited September 18Sep 18 by TheGCat

23 hours ago, BastiKA84 said:

Edit: Ich habe Gemini meine Diagnostics analysieren lassen. Da gibt es die Empfehlung, dass ich von macvaln auf ipvlan umstellen soll. Aber ich nutze macvlan dank der Friotzbox Problematik von unraid 6 entsprechend schon ein paar Jahre. Das sehe ich nicht als Problem an, sonst hätte ich ja in den letzten Jahren mehr Probleme haben müssen...

exakt, verträgt sich auch nicht (ipvlan und Fritz) und die crashes haben sich auch im log angekündigt.

Harte Crash's (reboots) ohne logs sind (leider) fast immer Hardware und es bleibt meist nur "trial & error" ... von A-Z.

wenn das System "einfriert" kann es auch öfters Software sein, sieht man meist jedoch in den logs wenn die dann persistent aktiviert sind.

Viel Erfolg.

Der Server ist vorhin wieder abgestürzt und neugestartet. Die letzten Zeilen vom Log waren:
Sep 18 15:56:06 Tower emhttpd: read SMART /dev/sdg Sep 18 15:56:17 Tower emhttpd: read SMART /dev/sdd Sep 18 16:28:00 Tower emhttpd: spinning down /dev/sdg Sep 18 16:28:00 Tower emhttpd: spinning down /dev/sdd Sep 18 16:58:21 Tower emhttpd: read SMART /dev/sdg Sep 18 16:58:21 Tower emhttpd: read SMART /dev/sdd Sep 18 17:30:25 Tower emhttpd: spinning down /dev/sdg Sep 18 17:30:25 Tower emhttpd: spinning down /dev/sdd Sep 18 17:57:49 Tower emhttpd: read SMART /dev/sdg Sep 18 17:57:59 Tower emhttpd: read SMART /dev/sdd Sep 18 18:30:20 Tower emhttpd: spinning down /dev/sdg Sep 18 18:30:20 Tower emhttpd: spinning down /dev/sdd

Und das nächste Log fängt einfach mit der Startroutine an:
Sep 18 18:38:20 Tower kernel: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul 6 15:22:03 PDT 2026 Sep 18 18:38:20 Tower kernel: Command line: BOOT_IMAGE=/boot@/bzimage unraidguimode acpi_enforce_resources=lax usbcore.autosuspend=-1 pcie_aspm=off pcie_port_pm=off unraiduuid=1533913480426968572 Sep 18 18:38:20 Tower kernel: BIOS-provided physical RAM map: Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009d1efff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000009d1f000-0x0000000009ffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a000000-0x000000000a1fffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a200000-0x000000000a20dfff] ACPI NVS Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a20e000-0x00000000c30e2fff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c30e3000-0x00000000c30e3fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c30e4000-0x00000000c9cf4fff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c9cf5000-0x00000000ca0a8fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca0a9000-0x00000000ca212fff] ACPI data Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca213000-0x00000000ca9b3fff] ACPI NVS Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca9b4000-0x00000000cb9fefff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000cb9ff000-0x00000000ccffffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000cd000000-0x00000000cfffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fd200000-0x00000000fd2fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fd400000-0x00000000fd5fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fea00000-0x00000000fea0ffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000feb80000-0x00000000fec01fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fedc2000-0x00000000fedcffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fedd4000-0x00000000fedd5fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000100000000-0x000000102f2fffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000102f300000-0x000000102fffffff] reserved Sep 18 18:38:20 Tower kernel: NX (Execute Disable) protection: active Sep 18 18:38:20 Tower kernel: APIC: Static calls initialized Sep 18 18:38:20 Tower kernel: efi: EFI v2.7 by American Megatrends Sep 18 18:38:20 Tower kernel: efi: ACPI=0xca212000 ACPI 2.0=0xca212014 TPMFinalLog=0xca967000 SMBIOS=0xcb7b6000 SMBIOS 3.0=0xcb7b5000 MEMATTR=0xc5c7b018 ESRT=0xc7b2e798 INITRD=0xc12a9b18 RNG=0xca1eec18 TPMEventLog=0xca0e9018 Sep 18 18:38:20 Tower kernel: random: crng init done Sep 18 18:38:20 Tower kernel: efi: Remove mem79: MMIO range=[0xf0000000-0xf7ffffff] (128MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xf0000000-0xf7ffffff] reserved Sep 18 18:38:20 Tower kernel: efi: Remove mem80: MMIO range=[0xfd200000-0xfd2fffff] (1MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfd200000-0xfd2fffff] reserved Sep 18 18:38:20 Tower kernel: efi: Remove mem81: MMIO range=[0xfd400000-0xfd5fffff] (2MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfd400000-0xfd5fffff] reserved Sep 18 18:38:20 Tower kernel: efi: Not removing mem82: MMIO range=[0xfea00000-0xfea0ffff] (64KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Remove mem83: MMIO range=[0xfeb80000-0xfec01fff] (0MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfeb80000-0xfec01fff] reserved Sep 18 18:38:20 Tower kernel: efi: Not removing mem84: MMIO range=[0xfec10000-0xfec10fff] (4KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem85: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem86: MMIO range=[0xfed40000-0xfed44fff] (20KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem87: MMIO range=[0xfed80000-0xfed8ffff] (64KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem88: MMIO range=[0xfedc2000-0xfedcffff] (56KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem89: MMIO range=[0xfedd4000-0xfedd5fff] (8KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Remove mem90: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xff000000-0xffffffff] reserved Sep 18 18:38:20 Tower kernel: SMBIOS 3.3.0 present. Sep 18 18:38:20 Tower kernel: DMI: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 5055 09/10/2026 Sep 18 18:38:20 Tower kernel: DMI: Memory slots populated: 4/4

Ich kann mir nicht vorstellen, dass da ein Problem mit der CPU vorliegt. Die hatte ja nichts zu tun, und lungerte im idle rum. Ich vermute weiterhin irgendeine Energiesparoption

Edited September 18Sep 18 by BastiKA84

Sorry für Doppelpost.

Der Server ist heute morgen wieder abgestürzt, wieder gibt das Log nichts her. Also habe ich dann jetzt doch Prime95 probiert. Im Smallest liefen die 12 Kerne ohne HT für ein paar Tests durch, kein Problem. Wenn ich den small Test starte mit 12 Kernen ohne HT kann ich die Maus noch ein paar Sekunden bewegen, dann friert die ein. Auch 10 Minuten warten hat da nichts gemacht, das System war wirklich voll weg...

Jetzt kann es also entweder die CPU sein, das Mainboard oder eventuell das Netzteil (das hatte ich auch getauscht, aber irgendwie nicht als relevant angesehen im Ausgangspost). Das Netzteil ist ein 1200W Enermax Revolution. Das sollte also eigentlich genügend Spielraum haben...

Zum Testen kann ich das Mainboard tauschen; ich habe ja noch den Vorgänger hier. Nur bekomme ich ich da nicht alle Festplatten ran... Eine Ersatz-CPU habe ich aktuell nicht, und auch kein Ersatznetzteil... CPU bekomme ich bestimmt noch irgendwo ausgeliehen, Netzteil wird schwierig. Besonders, weil es leider ein Enermax ist, und an diesem sind die Stromkabel anders verkabelt, es als bei wielen anderen Netzteilen

Ich kann nochmal die Stromkabel kontrollieren, vielleicht sitzt das CPU oder ATX Kabel nicht richtig... Ansonsten bin ich mit meinem Latein am Ende

Mal eine blöde Frage, aber hast du dir die Temperaturen mal angesehen?

Die CPU ist im idle meistens bei 40 bis 45 Grad.

Ich habe noch bisschen mit den BIOS Einstellungen der Stromversorgung rum gespielt. Ich habe gesehen, dass es an zwei Stellen den Preission Overdrive Boost gibt. Einen hatte ich deaktiviert, den anderen nicht. Nachdem beide deaktiviert waren, konnte ich Prime95 schon länger laufen lassen. Ist dann dennoch wieder abgestürzt (dieses Mal ein Absturz und kein freeze). Ich habe mich dann erinnert, dass ich diese CPU nicht im eco Modus betreiben konnte. Das könnte jetzt im Nachhinein doch auf degradierte CPU hindeuten, oder? Ich Versuche es mal mit einer minimalen Spannungsversorgung von 0.025 V, eventuell noch 0.050 V. Wenn das nichts bringt, muss ich mir irgendwo ein Netzteil ausleihen. Die Festplatten müssen ja nicht angeschlossen, mainboard, CPU, Grafikkarte reicht ja schon.

Ich musste die Spannung um 0.0500 v erhöhen. Jetzt läuft Prime95 seit 15 Minuten. Die CPU hat eine Temperatur von rund 65° C. Ich warte mal eine Stunde ab. Danach gehe ich wieder in den Server betrieb über.

Nach 90 Minuten habe ich den Test gestoppt. Die Temperatur vom Prozessor ist innerhalb kürzester Zeit wieder auf 40°C gefallen.

Jetzt ist wieder Server Betrieb angesagt. Mal schauen, ob er dieses Mal mehr als 26 Stunden (Rekord innerhalb der letzten Woche) schafft.

Vielen Dank @TheGCat fürs die Tipps! An eine Degeneration habe ich überhaupt nicht gedacht beim 5000er Ryzen!

On 9/19/2026 at 7:50 PM, BastiKA84 said:

Jetzt ist wieder Server Betrieb angesagt. Mal schauen, ob er dieses Mal mehr als 26 Stunden (Rekord innerhalb der letzten Woche) schafft.

eine klitzekleine Anmerkung meinerseits:

Wenn Du einen Server 24/7 laufen lassen willst und jetzt schon mit höheren Spannungen arbeiten musst um das System irgendwie stabil zu bekommen, wäre das für mich nicht vertrauenserweckend und ein Warnsignal.

Ich würde schon mal Geld ansammeln um bei Bedarf (in Monaten?) dann doch Hardware tauschen zu können, denn wenn die CPU schon jetzt degeneriert sein könnte kann sich das auch fortsetzen.

Da hast du definitiv recht. Ich hatte schon mal geschaut und würde zukünftig zum Ryzen 9 5900XT greifen, dann allerdings als Neuware. Einen Preisalarm habe ich mir schon mal gesetzt. Trotzdem hoffe ich, dass mein alter 5900X noch mindestens ein Jahr schafft. Die nächste Anschaffung sollte eine 32 GB Grafikkarte für KI sein. Die rund 250 - 300 € für eine neue CPU sollten eben in die Grafikkarte fließen.

Hmm, die CPU muss wohl früher kommen... Bis heute morgen ca. 8.00 Uhr lief der Server ohne Probleme. Dann habe ich von vier Dockern die WebGUI aufgerufen, Absturz und Neustart. Jetzt rund 2,5 h später lief der parity check und parallel ein Download in SABnzb und wieder Absturz und Neustart... 😭

On 9/17/2026 at 6:15 PM, TheGCat said:

Aber auch Ryzen CPUs sterben hin und wieder mal.

Ich finde den Thread sehr interessant, da ich davon bei AMD Ryzen bislang noch nie gehört habe.

In meiner Familie hab ich seit 2018 drei 2000er, zwei 3000er und zwei 5000er Ryzen zusammengebaut, die seither im Einsatz sind und ohne Probleme laufen (zwei davon hab ich zudem gebraucht erworben), aber zugegeben läuft davon keiner 24/7, dafür sind sie mir zu ineffizient im idle 😉

Mein einziger Rechner, der jemals ähnliche Abstürz-Probleme zeigte, war mein Intel-Backupserver, wo offenbar Sockelkontakte auf dem gebrauchten Board verbogen waren, was bei Sockel1700 angeblich öfter mal auftritt 🤔. Nach Board-Tausch war das Problem weg.

Solche Probleme sind bei AMD-Sockeln per Design eher ausgeschlossen, von daher bin ich sehr gespannt, ob's wirklich an der CPU liegt, soo alt ist sie ja nun auch nicht....

Aber wie repräsentativ ist deine persönliche Erfahrung denn? Ich habe beruflich damit zu tun und da werden nicht 5 abgezählte PCs für die Familie gebaut, sondern deutlich mehr. Wenn von 1000 CPUs eine kaputt geht ist das schon viel. Normalerweise halten die ewig. Aber nichtsdestotrotz kann jede CPU den Hardwaretod finden. Meistens ist es ja "nur" ein Kern, der fehlerhaft ist und sich schlicht "verrechnet" oder der integrierte Speichercontroller hat eine Macke. Tatsache ist aber, so kann man mit dem Ding nicht mehr wirklich arbeiten, denn die Konsequenzen wären dann entweder ständige sporadische Abstürze oder aber, das System friert komplett ein.

Das CPUs sterben ist dennoch sehr selten!

Seit AM5 gibt es die Sockelprobleme aber auch bei AMD, denn ab dem AM5 Sockel setzen die wie Intel auch auf einen LGA Sockel. Da können dann auch die Pins wie bei den Intel Sockeln verbiegen.

Edited September 22Sep 22 by TheGCat

4 hours ago, BastiKA84 said:

Hmm, die CPU muss wohl früher kommen... Bis heute morgen ca. 8.00 Uhr lief der Server ohne Probleme. Dann habe ich von vier Dockern die WebGUI aufgerufen, Absturz und Neustart. Jetzt rund 2,5 h später lief der parity check und parallel ein Download in SABnzb und wieder Absturz und Neustart... 😭

Ich kann dir nur raten das mal deutlich länger zu testen!!! Zur Not mal 24 Stunden am Stück. Du hast ja selber schon gesagt, dass das innerhalb 24 Stunden auftritt. Um also sicher zu gehen, dass es nicht mehr auftritt, solltest du das auch mal mindestens 24 Stunden laufen lassen. Vor allem: sollte er dir dann anzeigen, das sich ein Kern verrechnet, ist die CPU defekt.

15 minutes ago, TheGCat said:

Aber wie repräsentativ ist deine persönliche Erfahrung denn?

natürlich gar nicht 😂

16 minutes ago, TheGCat said:

Wenn von 1000 CPUs eine kaputt geht ist das schon viel.

ja ok, ich hatte das so verstanden, als würden die Ryzens degenerieren, das hörte sich so an als käme das öfter vor....und davon hab ich halt noch nie gehört und wollte nur zum Ausdruck bringen, dass ich durchaus auch einige ältere Systeme im Einsatz habe, die keinerlei Anzeichen diesbzgl. machen.

Beruflich setzen wir außer in Mitarbeiter Laptops keine Comsumer CPUs ein, daher hab ich da auch keine Erfahrungswerte, hab aber auch noch nie mitbekommen, dass wir im RZ Umfeld defekte CPUs tauschen.

19 minutes ago, TheGCat said:

Das CPUs sterben ist dennoch sehr selten!

das denke ich auch, bin wie gesagt gespannt auf das Ergebnis

6 minutes ago, TheGCat said:

Ich kann dir nur raten das mal deutlich länger zu testen!!! Zur Not mal 24 Stunden am Stück. Du hast ja selber schon gesagt, dass das innerhalb 24 Stunden auftritt. Um also sicher zu gehen, dass es nicht mehr auftritt, solltest du das auch mal mindestens 24 Stunden laufen lassen. Vor allem: sollte er dir dann anzeigen, das sich ein Kern verrechnet, ist die CPU defekt.

OK, dass muss ich dann demnächst machen. Ich bin ab morgen für eine Woche nicht Zuhause. Den Server schalte ich vorher aus, da die Lüfter bei 100% drehen, wenn er neustartet (Fancontrol ist installiert aber aus irgendeinem Grund muss ich nach einem Restart aktiv auf den aktualisieren Knopf drücken, damit die verwaltet werden.) Das will ich meiner Frau und meiner Katze nicht antun 😅 Also ab 01.10. widme ich mich nochmal dem Testing. Der mein letzter Test lief ja 90 Minuten problemlos, daher dachte ich, es sei OK. Heute morgen waren es vier WebGUIs während eines Parity Checks, das ist zwar spontane Last, aber alles andere 100% auf allen Cores.
Wenn ich den Test mache, muss ich erstmal unter dem Ubuntu Live noch eine Software zur Lüftersteuerung installieren, sonst habe ich während des Tests wieder das Problem, dass die Lautstärke zu viel für die Familie ist ;)

Servus,

falls du immer noch Probleme hast. Habe/Hatte auch so ähnliche Probleme. Wird an Docker liegen und zwar mit der kombi macvlan. Mit jeder Unraid version gibt es mal mehr und weniger Probleme. Aktuell nutze ich die 7.4.0 Beta 2 und läuft 30 tage ohne Absturz durch.

Füge mal folgendes in die "go" Datei ein:

ethtool -A eth0 autoneg off rx off tx off

ethtool -K eth0 gso off gro off tso off

Danach einen Neustart machen und dann abwarten.

Damit wird die Flow-Control und Offloading Funktion deaktiviert. Damit lief der Server zumindest bei mir schon mal länger durch.

Es kann auch an bestimmten Dockern liegen die so einen Fehler hervorrufen kann.

Habe etliches gelesen über Docker und macvlan. Anscheinend sollte man Docker auf eine separate Netzwerkkarte tun. Soll am besten funktionieren.