Hi,

I've been using UnRAID for a few weeks/months and love it, but I’m facing an issue where the system becomes unresponsive, and I can’t access the UI (locally or remotely). The only way to restore access is a physical reboot, which is inconvenient due to its placement.

I suspect this happens when the CPU is pushed too hard—once, I saw all cores hitting 100% before the system froze. This often occurs when multiple users make heavy requests on Overseerr.

Is there a way to prevent this, such as limiting CPU usage or reserving some cores for system stability? Would underclocking help?

Thanks!

Enable the syslog server and post that after a crash together with the complete diagnostics.

5 hours ago, cazure said:

Hi,

I've been using UnRAID for a few weeks/months and love it, but I’m facing an issue where the system becomes unresponsive, and I can’t access the UI (locally or remotely). The only way to restore access is a physical reboot, which is inconvenient due to its placement.

I suspect this happens when the CPU is pushed too hard—once, I saw all cores hitting 100% before the system froze. This often occurs when multiple users make heavy requests on Overseerr.

Is there a way to prevent this, such as limiting CPU usage or reserving some cores for system stability? Would underclocking help?

Thanks!

 

Something that is not really discussed is that the CPU statistics on the unraid dashboard is deceiving.  What I mean is that it includes IO-WAIT. IO-Wait is cycles not doing anything because it's waiting on the hard-drives to finish whatever they're doing before the CPU can access what it needs to resume whatever it was doing. (this explanation might not be exactly "technically" correct but it really doesn't matter, the point is the same)

 

So when you see your CPU climbing to 100% utilization it might not actually be really at 100% utilization. It's more likely idle waiting on data/disks which gets represeted as CPU Load even though it's doing nothing.

 

What I suspect is happening is you're filling up your cache drive if you have one and it being full is causing your system to lock up because your docker containers are running out of disk space to operate. (99% of the time this is the issue)

 

To fix this you need either a larger cache or a dedicated disk just for dockers.

Sorry for the late reply.

I do have a very interesting setup right now. As it's a start of the full / complete build.
I have my storage on a Synnolgy NAS. But, due to lack of "power", I bought an old Z870, that will have all the brains. I'm very aware this is less of ideal. But this was currently the quickest fix for my issue, where I needed compute power, rather than storage.

I have 1 TB SSD inside the UnRAID system, but all the storage is on the Synology NAS.

@JorgeB I have a log service running now. When the issue happens again, I'll share them here. But this could be a long time
@MowMdown I will take this into consideration. But I'll be waiting for financial focus, that I can put in the UnRAID machine. Then some more HDD's, and some SSD's for cache will be brought into the system.

Thanks all, and have an incredible Sunday!

Goodday,

@JorgeB see the attached log files. I just haven't gotten any clue out of it what could be the reason for the sudden "unreachableness" of the system.

I was thinking, could it maybe have to do with Cloudflare clogging up?

syslog-previous syslog

Apr  5 14:10:09 UnRAID rc.nginx: Reloading Nginx server daemon...
Apr  5 14:10:10 UnRAID rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration...
Apr  5 14:10:10 UnRAID rc.nginx: /usr/sbin/nginx -t -c /etc/nginx/nginx.conf
Apr  5 14:10:10 UnRAID rc.nginx: Reloading Nginx server daemon configuration...
Apr  5 21:34:52 UnRAID elogind-daemon[2089]: Power key pressed short.
Apr  5 21:34:52 UnRAID elogind-daemon[2089]: Powering off...
Apr  5 21:34:52 UnRAID elogind-daemon[2089]: System is powering down.
Apr  5 21:34:52 UnRAID shutdown[95331]: shutting down for system halt

 

I assume the crash happened between these lines? If yes, I'm afraid that there's nothing relevant logged, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the individual docker containers.