Afrobaron

So far 14.5 days of uptime. The only thing different currently from previous is that I am booted into GUI mode. Going to run up to about 20 days uptime if all is well then I will reboot into headless mode (no GUI) and see how things run.

I discovered that most of the time I experienced this issue I had one or both of the following things going on. 1. Parity checks were running that were ting up the disk the info was sitting on. - My fix here was to install the parity check tuning plugin/addon to pause the check in the daytime hours when I was using the server more actively. 2. My disks were spun down due to in activity overnight. This was a just a slow initial access with normal access speeds afterward. - I was going to create a job that ran each morning to force a read or write on the pool that would spin them up but ultimately I went against the idea as there are days like on weekends I don't need to access the pool early. So I am just living with the slow initial access when my server has been idle for a long period. The only condition I saw both occur was when my VM pool was spun down (no VMs running) and my data pool was running parity check. The VM pool had a share on it that I was trying to move a file to from the data pool and the combined delays caused some issues. Very rare chance of occurrence now that parity check does not run when I am active.

I was able to find a global C states in the BIOS and disabled it for now. Now the clock starts ticking on up time to see if I can beat my most recent 5 day uptime. On a side note this server for the better part of two or more years has been a rock and had uptimes over 2 plus months at a time.

I'll give this a look and see what is in my BIOS and report back.

I have recently been running into an issue where my server that has in the past gone months without a reboot will no longer stay alive for more than 5 days (many times even shorter). I had moved the server box to a different physical location for a temporary basis while I rebuilt my network rack. After this I started having the issues. I thought at first maybe moving it made something come loose, but I have stripped the cables and card down then re-plugged them all. That has not resulted in any improvement in up time. I enabled syslog on the server and those logs have no entries at all around the times I am seeing that the server goes offline. Symptoms I see when the server hangs: - No ping response - No Dashboard webpage - No telnet/SSH - Dockers do not load webpages/respond to content requests. I have disabled the one VM I run from time to time, so the system is basically a over powered file server and Plex box at the moment. Even Plex is no getting almost no use at the moment. Diagnostics are attached and I am hoping someone here can help me figure out what is going on. Troubleshooting steps? Logs? I am seriously wide open to things? Side question, is there a way I monitor the power supply voltages on server? Just wondering if my power is dirty and causing the system to brown out and freeze. hades-diagnostics-20221002-1707.zip

bumping this item for attention. Problem is still going on.

I have on my network two windows 10 machines and a Mac. All three are having issues recently with my SMB shares from Unraid. The common issues is I can open windows explorer (or Mac Finder), browse to a shared folder. Sometimes teh share will open and load contents quickly, other times it will take up to 30 seconds. Browsing further into subfolders is hit or miss on if I get a quick load or not. Additionally, opening files, even small text files, can take extended periods and similar on a save of the file(s) from within an application like excel, notepad++, etc. I have user accounts on unraid, assigned them to shares, and have windows credential manager setup with the same user accounts (used tutorials from here to do this). This evening it has come to a point where Windows Explorer had to be forced closed in order to recover. The Unraid syslog shows the below in the code snip block from the same time area. Added note, all Unraid pages, and any docker with a web GUI work perfectly fine and show no signs or issues of anything wrong, just the SMB shares. This issue may have started after I used unbalance so I could remove a drive that was starting to have errors. I followed procedures for the drive removal and the array reconfig went fine with no data loss. Not sure if in my unbalnce run I moved anything that shouldn't have moved from other drives or pools (I don't think I did). However, it was after this move I started to experience the slow responses, and it has gotten worse over time. Running Unraid 6.9.2 (diagnostics attached) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.980729, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.980753, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.980777, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.982969, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.983008, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.983039, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:50:06 Hades smbd[14454]: [2021/09/20 19:50:06.983068, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Sep 20 19:50:06 Hades smbd[14454]: sys_path_to_bdev() failed for path [.]! Sep 20 19:54:24 Hades smbd[14454]: [2021/09/20 19:54:24.170706, 0] ../../source3/smbd/smb2_read.c:255(smb2_sendfile_send_data) Sep 20 19:54:24 Hades smbd[14454]: smb2_sendfile_send_data: sendfile failed for file Light Saber/_Completed Saber Configs/_Proffie/ProffieOS/blades/blade_id.h (Connection reset by peer) for client ipv4:10.0.0.34:53979. Terminating hades-diagnostics-20210920-2235.zip