January 13, 20251 yr Hallo zusammen, ich bin mit meinem Latein am Ende. Mein Unraid Server friert immer wieder einfach ein. Dann hilft nur ein harter Cut vom Strom und Reboot. Per SSH ist dann kein Connect mehr möglich. Anbei das Diagnostic Log. Vielleicht seht ihr Profis ja was im Log. Ich habe die Cache SSD im Verdacht gehabt, die wurde bereits kürzlich getauscht. Vielleicht ist es der RAM? Wäre das nächste Bauteil was ich austauschen würde. Vielleicht kann mir kja einer helfen? tower-diagnostics-20250113-2141.zip
January 14, 20251 yr 7 hours ago, unn4m3d said: Vielleicht kann mir kja einer helfen? in dem log sieht man mal nichts, war aber auch "frisch" nach einem Neustart. enable mal unter syslog server settings "mirror to flash" solange du auf Fehlersuche bist, da ist die Chance größer ... >> wenn der Fehler gefunden wurde wieder deaktivieren !!! ansonsten 1/ modprobe der iGPU, warum ? 2/ Netzwwerk, bond aktiv (einen Verbund mehrerer ...) mit einer NIC, deaktivieren 3/ du nutzt eine Realtek Karte ... mal mit Treiber versucht ? CA Apps, Realtek, passenden Treiber mal installieren (siehe changelogs ...) 4/ btrfs ... man sieht mal keine Fehler in den logs, aber auch gerne ... Suche oben rechts im Forum Hardware, echte Hardware Fehler enden meist in unkontrollierten Neustarts, meist ... nicht immer
January 14, 20251 yr Author Danke für dein Feedback. Ich werde darauf eingehen. 1/ Ich meine modprobe habe ich mal aktiviert als die GPU Treiber noch nicht standardmäßig geladen worden sind, um in Jellyfin und Tdarr Transcoding zu nutzen. Ist aber auch minimum 2 Jahre her und mein Gedächtnis an der Stelle löchrig. In diesem Thread wird ja auch darauf eingegangen. Überall steht immer nur wie man modprobe aktiviert bei der Intel GPU. Wie kann ich das easy wieder deaktivieren? 2/ Mit Netzwerk Bond meinst du die Nutzung mehrerer lokaler IP Adressen mit einer NIC? Unraid läuft bei mir mit der 192.168.178.108 und auf Unraid ist Adguard Home als Docker mit der 192.168.178.109 als lokaler DNS Server eingerichtet. Ich habe das damals sicherlich mit einem Tutorial eingerichtet wo mir das so empfohlen wurde. Ist es unkritisch Adguard Home auf der gleichen IP laufen zu lassen wie Unraid? Edit: Ich sehe gerade, dass der Timemachine Docker auch mit einer dedizierten IP läuft. Besonders ärgerlich ist natürlich, dass im Falle eines Systemabsturzes so immer das komplette Internet Zuhause ausfällt via WLAN, da die DNS Einträge nicht mehr aufgelöst werden von der Fritzbox und ich Remote keine Chance habe den Server neuzustarten. Kurzes Googlen hat ergeben, dass Bond eigentlich mehrere NICs zusammenschließt?! Also könnte ich das ggfs. einfach deaktivieren? Habe ein bisschen Angst mich auszusperren wenn ich daran herumfummel ohne das OK von einem Profi. 3/ Danke für den Hinweis. Habe den Treiber mal installiert und starte Unraid gleich neu. 4/ Von den Problemen die btrfs machen kann, habe ich schon vorab gelesen. Ohne Fehler in den Logs würde ich es dennoch damit erstmal belassen. /Allgemein Leider sind die Abstürze des Servers keinesfalls reproduzierbar. Bis gestern lief der Server 22 Tage durch. Dann gleich zwei Abstürze an einem Tag. Edited January 14, 20251 yr by unn4m3d
January 14, 20251 yr Community Expert 25 minutes ago, unn4m3d said: dass Bond eigentlich mehrere NICs zusammenschließt?! Also könnte ich das ggfs. einfach deaktivieren? Ja und Ja Ansonsten den Tipp von alturismo beherzigen und den Syslog server aktivieren. Nach einem Absturz kannst Du das Log dann vom Stick kopieren und hier einfügen.
January 14, 20251 yr Author 23 minutes ago, saber1 said: Ansonsten den Tipp von alturismo beherzigen und den Syslog server aktivieren. Nach einem Absturz kannst Du das Log dann vom Stick kopieren und hier einfügen. Danke, das habe ich schon aktiviert. Hoffe, das der Spuk bald ein Ende hat. Bond stelle ich jetzt auch aus.
January 24, 20251 yr Author Jetzt war es wieder soweit. Unraid hat sich aufgehangen. Anbei der zugehörige Syslog vom Bootvolume. Bin gespannt, ob ihr was findet! syslog-previous
January 24, 20251 yr 58 minutes ago, unn4m3d said: Anbei der zugehörige Syslog vom Bootvolume. Bin gespannt, ob ihr was findet! da war zwar ein trace am 14.01. .. aber lassen wir den mal außen vor hast du einen docker laufen wo sich permanent per ssh / sftp mit Unraid verbindet ? das ist so der Anfang com Ende ... Jan 24 15:54:39 Tower sshd-session[1412897]: Starting session: subsystem 'sftp' for root from 192.168.178.38 port 61210 id 0 Jan 24 15:55:40 Tower sshd-session[1412897]: Connection closed by 192.168.178.38 port 61210 Jan 24 15:55:40 Tower sshd-session[1412897]: Close session: user root from 192.168.178.38 port 61210 id 0 Jan 24 15:55:40 Tower sshd-session[1412897]: Transferred: sent 13856, received 9376 bytes Jan 24 15:55:40 Tower sshd-session[1412897]: Closing connection to 192.168.178.38 port 61210 Jan 24 15:55:40 Tower sshd-session[1412892]: pam_unix(sshd:session): session closed for user root Jan 24 15:59:43 Tower nginx: 2025/01/24 15:59:43 [alert] 10480#10480: worker process 10481 exited on signal 6 Jan 24 15:59:44 Tower nginx: 2025/01/24 15:59:44 [alert] 10480#10480: worker process 1437243 exited on signal 6 Jan 24 15:59:46 Tower nginx: 2025/01/24 15:59:46 [alert] 10480#10480: worker process 1437315 exited on signal 6 Jan 24 15:59:48 Tower nginx: 2025/01/24 15:59:48 [alert] 10480#10480: worker process 1437558 exited on signal 6 Jan 24 15:59:50 Tower nginx: 2025/01/24 15:59:50 [alert] 10480#10480: worker process 1437653 exited on signal 6 Jan 24 15:59:50 Tower nginx: 2025/01/24 15:59:50 [alert] 10480#10480: worker process 1437755 exited on signal 6 Jan 24 15:59:52 Tower nginx: 2025/01/24 15:59:52 [alert] 10480#10480: worker process 1437759 exited on signal 6 Jan 24 15:59:54 Tower nginx: 2025/01/24 15:59:54 [alert] 10480#10480: worker process 1438010 exited on signal 6 Jan 24 15:59:54 Tower nginx: 2025/01/24 15:59:54 [alert] 10480#10480: worker process 1438067 exited on signal 6 Jan 24 15:59:56 Tower nginx: 2025/01/24 15:59:56 [alert] 10480#10480: worker process 1438114 exited on signal 6 Jan 24 15:59:56 Tower nginx: 2025/01/24 15:59:56 [alert] 10480#10480: worker process 1438194 exited on signal 6 Jan 24 15:59:58 Tower nginx: 2025/01/24 15:59:58 [alert] 10480#10480: worker process 1438195 exited on signal 6 ... .. . wenn ja, schätze mal was mit backups weil auch immer alle docker anscheinend restarted werden usw ... und wieviel Ram hast du ? schalte das mal ab was auch immer das ist zum testen ... @JorgeB may an idea what could kill Unraids tasks ?
January 25, 20251 yr Author Der sftp connect kommt von meinem Macbook und nicht von einem Docker Container. Da habe ich immer Filezilla an und war da zu der Zeit gerade am gucken wegen der unverständlich großen Größe der Mariadb Logs. Siehe den anderen Thread von mir. Ich habe 16 GB Ram im System verbaut. Sollte ich ggfs ein Upgrade auf 32GB in Erwägung ziehen? Für Backups nutze ich zum einen den Timemachine Docker fürs Macbook und ich habe aber auf dem Unraid System auch das Appdata Backup Plugin installiert. Google Recherche ergaben, dass andere User dieses Problem im Zusammenhang mit Transcoding in Plex hatten. Ich nutze kein Plex sondern Jellyfin. Aber ich nutze auch Tdarr um x264 Inhalte in x265 zu konvertieren. Den Docker Container habe ich gerade im Verdacht.
January 25, 20251 yr 9 minutes ago, unn4m3d said: Da habe ich immer Filezilla an und war da zu der Zeit gerade am gucken wegen der unverständlich großen Größe der Mariadb Logs. Siehe den anderen Thread von mir. ok, aber da sind 2 "Clients", 192... (dein mac) und 172... (ein Docker) auch hier kommen sehr viele Einträge . .. ... Zeile 6421: Jan 24 18:35:04 Tower sshd-session[1769821]: Connection from 172.18.0.6 port 49876 on 192.168.178.108 port 22 rdomain "" Zeile 6422: Jan 24 18:35:05 Tower sshd-session[1769821]: Accepted password for root from 172.18.0.6 port 49876 ssh2 Zeile 6425: Jan 24 18:35:05 Tower sshd-session[1769828]: Starting session: subsystem 'sftp' for root from 172.18.0.6 port 49876 id 0 Zeile 6429: Jan 24 20:36:19 Tower sshd-session[1769828]: Connection closed by 172.18.0.6 port 49876 Zeile 6430: Jan 24 20:36:19 Tower sshd-session[1769828]: Close session: user root from 172.18.0.6 port 49876 id 0 Zeile 6432: Jan 24 20:36:19 Tower sshd-session[1769828]: Closing connection to 172.18.0.6 port 49876 Zeile 6434: Jan 24 20:36:19 Tower sshd-session[1709087]: Connection closed by 172.18.0.6 port 45048 Zeile 6435: Jan 24 20:36:19 Tower sshd-session[1709087]: Close session: user root from 172.18.0.6 port 45048 id 0 Zeile 6437: Jan 24 20:36:19 Tower sshd-session[1709087]: Closing connection to 172.18.0.6 port 45048 nun ja ... der "kill" deutet normal auf sehr viele open sessions ... normal jedoch webui ... und dann friert mal gerne was ein bis man die open sessions schließt. es gab oder gibt diverse plugins, dockers, ... wo open sessions öffnen zum Auslesen usw usw ... daher die Frage. könnte mehr RAM helfen, eventuell ... aber daran würde ich das jetzt bei 16 GB nicht unbedingt fest machen. wenn du viel encodest, landet da ggf. was im RAM was den nicht sauber frei macht ... Jelly beispielsweise ist ein Kandidat welcher gerne bis zum Limit schreibt und nicht selbst einen cleanup ausführt, ja ... aber dazu müsste der Jelly cache auch im RAM laufen, per se läuft der einem mount /cache<>/mnt/user/appdata/jellyfin/cache ... das sollte es standardmäßig nicht sein. Plex beispielsweise räumt auf wenn es eng wird und löscht "ältere" Dateien ... Design Frage, Jelly (und Emby) wollen das man immer direkt wieder zurück zum Start gehen kann ohne "neu" anfassen zu müssen, Plex killt einfach die "alte" Timeframe und wenn man da retour springt wird neu geladen, das nur als Info. TDARR nutze ich nicht, ich encode mit meinem eigenen tool, daher kann ich das schwer beurteilen ... ob da was im RAM landet und wenn ja, wieviel. beobachte mal die RAM Last während da was läuft, könnte ein Auslöser dafür sein ... mehr sieht man in dem syslog nicht ... keine ernsthaften Fehler, nur das es irgendwann abschmiert ... sorry, mehr sehe ich da nicht.
January 25, 20251 yr 11 hours ago, alturismo said: may an idea what could kill Unraids tasks ? Sometimes helps booting in safe mode and/or closing any browser windows open to the GUI, only open when you need to use it then close again.
February 23, 20251 yr Author Ich habe wieder Abstürze. Jetzt allerdings im 10 Minuten Takt. Anbei das Syslog. Kann da jemand was auffälliges drin lesen? Danke und Grüße unn4m3d syslog-previous
February 23, 20251 yr Author Und hier schon der nächste Syslog. Ich habe erstmal die TDARR Docker Container abgestellt, da der CPU Fehler kam während TDARR transcodiert hat. syslog-previous
February 23, 20251 yr Der inotify calltrace hat nix damit zu tun On 2/20/2025 at 5:14 PM, JorgeB said: It happens to everyone, it's a kernel issue, and apparently that should not show as a call trace and will be removed: https://lore.kernel.org/lkml/CAOQ4uxibFVCGBEORDHjUuB_b6ELq8NdGaNv+Srz9rzQAdh=4OQ@mail.gmail.com/T/
February 23, 20251 yr Author Tatsächlich scheint es mit TDARR zusammenzuhängen. Jetzt gabs keine Abstürze mehr. Davor wie gesagt mehrfach reproduzierbar in kurzer Zeit.
February 24, 20251 yr Community Expert Da sonst nichts vorhanden ist, würde ich den Kernel Fehler als Ursache sehen. TDARR hat denke ich einen inotifywait auf bestimmte Verzeichnisse laufen, damit der Dateiänderungen mitbekommt und dieses Verzeichnis löst dann irgendwas aus. Vielleicht ein Dateisystem-Fehler. ich würde mal die betroffenen Festplatten reparieren. Das sollte man bei Crashes sowieso machen. Kann man bei TDARR diese automatische Überwachung deaktivieren? Dann das mal ausprobieren, ob er dadurch nicht mehr abstürzt. Also erst mal nur um sich dem Problem zu nähern. Wenn das dann klar ist, sollte man prüfen auf welche Art TDARR das Verzeichnis überwacht. Also ist das ein 1:1 Pfad, der durchgeschliffen wird an den Container oder ein Mount auf einen anderen Server oder ein Hauptpfad von Unraid und evtl gibt es dadurch einen Konflikt, den man mit mit Slave oder Shared lösen kann?!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.