stanger89

Hm, unfortunately it doesn't appear to be that. "Woke up" to find the same issue again this morning. Though it looks like this syslog is "complete from boot, and seems to have caught when the csrf errors started. For reference here's the first few lines of top: top - 06:25:55 up 11 days, 20:12, 0 users, load average: 2.46, 3.59, 3.38 Tasks: 486 total, 1 running, 484 sleeping, 0 stopped, 1 zombie %Cpu(s): 10.7 us, 10.4 sy, 0.0 ni, 78.6 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 15911.8 total, 506.8 free, 6988.2 used, 8416.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 7383.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12672 root 20 0 1299380 444536 924 S 93.4 2.7 1820:31 shfs 16740 nobody 20 0 6915712 1.0g 6320 S 35.0 6.4 750:20.26 Code42Service 19296 root 20 0 4364 2684 2156 S 21.5 0.0 0:01.05 find 13569 root 20 0 1659880 101188 46828 S 2.6 0.6 53:21.99 dockerd 13589 root 20 0 1563424 45048 24912 S 2.3 0.3 35:56.47 containerd 7149 chad 20 0 1409364 133668 73572 S 1.7 0.8 0:20.10 mediacenter28 19354 root 20 0 150380 32084 25884 S 1.7 0.2 0:00.05 docker unraid-diagnostics-20220406-0622.zip

Thanks, yeah I've been rebooting when I've run into it, but I was wondering if there was something to check/change to avoid it in the future. I did find, thanks to that link/info, that I had an obsolete plugin (old preclear disk) that I removed. Hopefully it was that.

I initially posted this here, and I did replace my flash drive (was probably time) but I've been having the issue where the state folder under /usr/local/emhttp disappears and the web GUI is filled with errors like "Warning: parse_ini_file(/usr/local/emhttp/state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php on line 41" The server continues running fine, I can access the shell and all. And I can reboot from the shell and everything will be happy again, for a while, a couple weeks, month+, I haven't been able to find a pattern to it. Running top in the shell the server doesn't appear to be out of memory, less than half used. So far it's just a minor annoyance, but it seems like something I should take care of. Anyone have any thoughts? unraid-diagnostics-20220325-0932.zip

Well you guys might have been right, maybe it wasn't the flash drive (still sorta glad I have a new one), I'm seeing the same symptoms rather frequently now. I thought I had a docker eating all my memory (jrivermc28), but I setup a script to restart it every night, so I don't think that's it. Here's what I've seen, I had it happen yesterday where the web GUI was riddled with "Warning: parse_ini_file(" errors, restarted the server it was fine. Now this morning (now) it happened again. I was actually looking at some pages, checking the stats page looking at memory usage, I'd restarted the jriver docker since it was up to about 1.6GB of memory. It was shortly after that, that I went to a different web gui page and was greeted with all the parse_ini_file errors. This time I do still have a /boot. Actually I can still see/read the ini files from the unraid shell in /var/local/emhttp I've attached the last two sets of diagnostics if anyone has any ideas? Thanks unraid-diagnostics-20220110-1351.zip unraid-diagnostics-20220111-0740.zip

Yeah, I saw that about blacklisting sticks before I did it, and I know what you're saying, but that original stick was a 2GB Cruzer, probably 11 years old. And on top of that it stuck out of the back and was pretty easy to bump, so I wouldn't really say changing sticks was "for the fun of it", more like, even if it was just because it got bumped, I don't feel like risking it going forward.

Thanks for the help, just wanted to make sure I did things in a way that didn't make things worse. Swapped out the stick, the parity check is running and all appears fine. FYI: After I shutdown the server ("powerdown" is the command that worked for me), I pulled the USB stick out and stuck it in my main PC. Windows said it needed to be checked, but found no issues. Turned out the flash drive appears fine. Well out of an abundance of caution I replaced it anyway with a Cruzer Fit I wasn't using. So while I had a backup from a few days ago from the Community Applications plugin, I was able to copy the config over from the "failed" stick to the new one.

It does look like I've got a backup from a few days ago. I kind of figured odds weren't high, but I'd seen some reports of similar errors from people just bumping their flash drive, so I wasn't sure. I'll have to look into flash drive recommendations again now. Since emhttp is completely dead, at least for the purposes of shutdown, is running "shutdown" from the command line the right way to do it now? I remember a few years ago you were supposed to manually stop the array first.

So from what I've read here, and looking at my logs, I'm guessing my Flash drive died, seems I have no /boot and I'm seeing lots of "Warning: parse_ini_file(state/*.ini)" errors in the web GUI. Ironically(?) the server and all the services seem to be running happily, so the question is, dare I just reboot, I'd have to do it through the command line (shutdown -r?). Is there anything I should do prior to that to make sure that the machine will happily boot on restart? Mainly since the server seems content right now, I'd like to get everything prepared so I don't want to restart it into a non-functional state. Thanks unraid-diagnostics-20210924-0721.zip

That's really interesting, one of my Windows PC (only one running Windows 10 Pro if that matters) has been having an issue ever since the 6.8 update (I think). At first I thought it might be the same issue that those folks with 10's of thousands of files in a directory were seeing, but it only affects one of my Windows machine. The problem I'm having is that browsing my unraid box is incredibly slow over samba, and right now Windows is bugging me that my file history share is gone. And indeed when I tried to browse to \\unraid\backup (the share where that's located), it took, 30, maybe a minute or more to come up (didn't think to actually time it). Now the odd thing for me is, if I go to \\unraid.local\backup, things are just as snappy as I'd expect. I haven't had to do this on any of my other Windows PCs.