-
7.3.1 - System becomes not responsive after upgrade
Turns out a container that was shut down (and NOT set to auto-start) turned itself on and was causing all of this. Odd behavior and is what had me a bit confused. Thanks for your patience and assistance.
-
7.3.1 - System becomes not responsive after upgrade
Thanks for finding that. I did update container configs to limit RAM usage. The most recent crash was CPU resources depleted. Logs for that attached. Have reconfigured CPU pinning to be more restrictive since then. Also configured max RAM settings for containers as suggested. It should be noted that I have downgraded back to 7.2.4 but there has been no improvement. Considering updating BIOS for my MB as there are updates available. System had been stable prior to attempted update to Unraid 7.3.1 so not sure. syslog-Rocinante (1).log
-
7.3.1 - System becomes not responsive after upgrade
Woke up to the system not responsive again. Though after a few minutes the GUI actually loads and can SSH to the box. Now we have logs prior to shutdown. syslog-Rocinante.log
-
7.3.1 - System becomes not responsive after upgrade
Thanks a ton for your help. Changed Global Share Settings to max as well as the step in your link (touch /boot/config/fastusr). Will see how it goes. As for CPU and RAM resources, I'd be surprised if those were exhausted. Granted I've only got two out of over a dozen dockers running but it is still crashing with just the two. Took your advice though and pinned CPUs. I set CPUs 2-11 for Docker and left 0-1 for the system. Does this look reasonable? Never messed with these settings before. Didn't do anything with CPU isolation fwiw. Thanks again.
-
7.3.1 - System becomes not responsive after upgrade
Hopefully this captured it all. I am in the process of converting an old RasPi into a Syslog server for what that is worth. syslog-previous
-
7.3.1 - System becomes not responsive after upgrade
Upgraded from 7.2.4 straight to 7.3.1 Upgrade went smoothly. System rebooted, was able to spin up drives and started docker containers. All seemed fine. Went to bed and woke up to the server not being accessible on local network. Web GUI would not load, not responding to ping. Had to perform unclean shutdown. Upon reboot, things began working again. But the cycle began again, went to bed and server was not responsive the next morning. Considering downgrading back to 7.2.4 but wanted to post here first. The Downgrade Unraid OS page recommended posting here before attempting that so here I am. There are some other issues as well since the upgrade. Tailscale plugin does not work. At least one container will not start properly which basically kills a stack of other containers. Luckily Pi-hole and Plex still work assuming the server is running properly. rocinante-diagnostics-20260605-2046.zip
-
MACGoof started following 7.3.1 - System becomes not responsive after upgrade
-
[Support] binhex - Radarr
Have you tried to force update Radarr and Deluge? Might help as, from what I understand, that rebuilds them
-
[Support] binhex - Radarr
**Ignore the below, the Radarr issue was a misconfiguration. Now I just need to work through why Radarr and Overseerr are not on speaking terms.** Hi all, hope everyone is doing well. If you would, please help make Radarr behave. Radarr has suddenly stopped talking to my indexer. Sonarr is working perfectly using the same indexer. I have uninstalled and reinstalled Radarr/renewed my indexer API/removed Indexer from Radarr settings but now cannot re-add due to error - (Unable to connect to indexer, please check your DNS settings and ensure IPv6 is working or disabled. Connection timed out (server ip address:8118). It should be noted that I use Wireguard via binhex-delugevpn and route all of my 'arr containers through that. They are all happy except for Radarr which gets the correct public IP and I can ping all but two default DNS servers from console. Other users have seen this error message and they were able to resolve by changing the NAME_SERVERS variable in the binhex-delugevpn container configs. I tried their recommendations, removing the default entries and to use only google (8.8.8.8,8.8.4.4) and then only cloudfare (1.1.1.1,1.0.0.1). I have tried keeping all of the default dns entries and only removing the two that do not respond to ping. In any case, any change to DNS breaks deluge which in turn breaks the other containers that run through it. Changing DNS also ghosts the NZBGET container forcing me to stop all containers and remove/re-install NZBGET. If i then revert back to the default dns entries in deluge and restart everything. All are happy except Radarr and I am back to the original issue of not being able to add my indexer back into Radarr. And I'm out of ideas short of trying a different container which seems like it could be tricky. Apologies for the word salad, hopefully that all makes sense. Any advice or tips would be greatly appreciated. radarr-logs.txt
-
[Support] binhex - NZBGet
Thanks for posting this. I followed your lead and set this up as well. Script works and the restarts at least allow some of my backlog to process a little at a time. Might tweak the frequency later but good enough for now. *edit: changed to every 30 minutes and is working well for me
-
Server Crashes
This is the way I'm leaning as well. I did boot into safe mode last week and it was stable for roughly a day. As soon as I rebooted into normal (no GUI), it started crashing again. I'm going ahead with my plan to return the MB and convert to Intel. Going with a side-grade/maybe slight upgrade i5-12400. This started as a way to use spare parts and has turned into a whole thing Thanks again for your time and help.
-
Server Crashes
Crashed again about 10 minutes ago. Here is the screen shot of kernel panic, logs and diags. Can anyone see anything relevant or do I have a hardware issue? Community Applications was the only plugin and Plex the only Docker running. What sort of things do you look for in the logs? Just errors I assume? I scan the previous logs and diags but never really see anything that stands out. rocinante-diagnostics-20240110-0547.zip syslog
-
Server Crashes
Thanks for confirming. I saw this warning in Docker logs. Is this anything to worry about? time="2024-01-10T05:20:43-08:00" level=warning msg="containerd config version `1` has been deprecated and will be removed in containerd v2.0, please switch to version `2`, see https://github.com/containerd/containerd/blob/main/docs/PLUGINS.md#version-header"
-
Server Crashes
I ran memtest overnight (10 hours) and it passed again with the manual settings I referred to above. (Memory 3200MT/s and flck 1600MT/s) Booted up and started the array. Then grabbed diagnostics and syslogs attached. Gonna let it run with zero pluggins and only the Plex docker running. rocinante-diagnostics-20240110-0547.zip rocinante-syslog-20240110-1353.zip
-
Server Crashes
Thank you for replying. This was completed prior to posting.
-
Server Crashes
Thank you so much for your input! Was starting to think I broke a forum rule or something since no one has replied. Yes, used the built-in memtest. Two cycles and it passed. Should I let it run for longer? Regarding the BIOS settings. I just now manually configured memory speed to be 3200MT/s and flck speed to be 1600MT/s per the recommendations I could find. Other than that, see attached for what I could find on voltages. I'm guessing you are referring to DRAM voltage which is set to Auto. Should I manually change that to something else? I didn't post my system specs, my fault. XMP is intel. AMD calls that DOCP and that setting is not enabled. It is set to Auto as well. Options are Auto/Manual/DOCP. Was honestly considering returning my MB and converting to an Intel system. I had this AMD processor, graphics card and power supply laying around so I bought the MB, RAM and storage for this build. AMD Ryzen 5 3600 NVIDIA RTX 2060 Asus ROG Strix B550-F x2 Crucial Pro RAM 64GB Kit DDR4 3200MT/s x2 WD Black SN850X 1TB cache x4 Seagate IronWolf Pro NAS 4TB Seasonic PX-850
MACGoof
Members
-
Joined
-
Last visited