Hi All,

 

I've had my unraid server setup and running ok for about the last 8 months or so. However, since upgrading to 6.12.4, I have had two instances where my NAS becomes unresponsive.

The first time it happened, I powered it off and then back on again, performed a parity scan and no issues were found.

Unfortunatly I hadn't had syslog enabled. So any data then was lost after the power cycle. When I had it happen last time, I was unable to ping the machine or connecting a display to the unit didn't give me anything. So there wasn't a lot I could do.

The second time around (happened this weekend just gone) I had syslog enabled. My first indication anything was wrong, was that one of the Docker containers I normally connect to was really slow to respond. I was able to log into the main GUI on my phone and I could see that the CPU was running 100% utilised across all the cores. Unfortunately I didn't have SSH enabled on the system, so I couldn't connect into it that way, and when I tried to goto the web gui to enable SSH again, it was no longer responsive, and I had to hard power it off again. (This time the parity scan did find one error, but it was corrected.)

I now have SSH enabled if it was to happen again to try and see what is hammering the CPU at the time. I have updated all my docker containers to their latest versions, but I don't have any culpret at this point as to what is causing the NAS to be unresponsive. 

I've checked the disk logs for all the drives attached to the system (including the USB) and I can't see any specific reason as to why this is happening. 

I'm open to any suggestions. Thanks in advance!
 

bignas-diagnostics-20231023-1115.zip

Edited October 23, 20232 yr by drrevenge
clarity

6 hours ago, drrevenge said:

I had syslog enabled

Also post that please.

2 hours ago, JorgeB said:

Also post that please.

Apologies I thought it was included in the diags.zip. 

syslog-192.168.0.34.log

Oct  4 13:46:56 BigNAS nginx: 2023/10/04 13:46:56 [error] 10889#10889: *211567 limiting requests, excess: 20.851 by zone "authlimit", client: 192.168.0.185, server: , request: "PROPFIND /login HTTP/1.1", host: "192.168.0.34"

 

I assume "client: 192.168.0.185" is your desktop? If yes try closing all browser windows opened to the GUI, only open when you need to interact with it and then close.

It's one of the computers in my house. I would have had the GUI open at some point. But is this honestly the reason for max CPU? This seems a like a bug that the GUI can't handle being open all the time. 

I will make sure I have nothing open on the GUI from here and see how we go.

I’ve not had any further repeats of the problem since closing all instances of the management GUI. Not a huge fan of the solution, I would imagine that you’d be able to leave it open, but I can deal with it. 
 

Thanks again for the assistance!