I've been having this issue recently - maybe a month or so - where nearly every other day, at a random time, the server with lock up.

First it starts with not being able to access containers, but they're still running (Plex for example), then several minutes later, the containers stop working too.

Like right now, I tried to shut down the server and the console is stuck at "Collecting data" after it said it was waiting 600 seconds for graceful shutdown.

But I can still access qBittorrent, although it's very laggy.

I have a PiKVM so I will remote into the CLI that way and try to log in with root.

I put the username root in, then it never prompts me for a password and eventually goes back to asking for a username.

I'll press the power button on my case and it'll start shutting down (Sending TERM signal, etc).

Then gets to a point where the shutdown stops. Like right now, it's kinda stuck at Generating diagnostics.

I end up having to force the computer to shutdown and then on bootup, the parity wants to start.

I have NO idea what the issue could even be. Server is about 2 years old, everything was running great until about a month ago.

Come to think of it... I may or may have no updated to 7.1.4 around that time.

I just... don't know what to look for and can't recreate it since I have no idea where to even start.

I was hoping you guys might have some insight based on my diagnostics file.

Thank you for any info you guys might have!

devante-nas-diagnostics-20251108-1731.zip

On the Docker page, click Container Size button at bottom and post the results.

4 hours ago, trurl said:

On the Docker page, click Container Size button at bottom and post the results.

OK, this is what it shows: https://pastebin.com/XCJRL0kL

Edited November 9, 2025Nov 9 by DevanteWeary

It may also be worth to enable the syslog server to see if it catches something.

20 hours ago, JorgeB said:

It may also be worth to enable the syslog server to see if it catches something.

Heya. (guess I'm not getting notifications form the forums anymore for some reason).

Anyway, I have syslog server enabled.

Both locally and to a syslog server (Graylog on the same Unraid server).

Actually, I just noticed I have it set to maximum 5MB with 4 files but the actual syslog file is 780 MiB.

OK it just happened again. Sucks man. At this rate, I'm gonna corrupt all my drives having to force the power off nearly everyday.

Here's the diagnostic, the syslog-previous, and the current syslog.

devante-nas-diagnostics-20251110-1022.zip syslog.txt syslog-previous.txt

Nov 10 09:48:29 Devante-NAS php-fpm[16205]: [WARNING] [pool www] child 4147253 exited on signal 9 (SIGKILL) after 336.491920 seconds from start

Nov 10 09:49:09 Devante-NAS php-fpm[16205]: [WARNING] [pool www] child 4148434 exited on signal 9 (SIGKILL) after 100.088481 seconds from start

Nov 10 09:49:47 Devante-NAS php-fpm[16205]: [WARNING] [pool www] child 4148453 exited on signal 9 (SIGKILL) after 127.996860 seconds from start

In my experience, these errors can be the result of the server being close to exhausting the memory, GUI can become extremely slow, like 1 minute to open the dashboard, try limiting the memory for VMs/docker services, or adding a little more RAM.

It could also be one or more containers hogging the CPU, try pinning only some cores to them, and leave cores 0/1 available for Unraid.

Also, recommend trying a couple of other things, go to Settings - Global share settings and set the Number of fuse File Descriptors to the max, and enable this:

https://docs.unraid.net/unraid-os/release-notes/7.0.0/#excessive-flash-drive-activity-slows-the-system-down

@JorgeB @trurl

Wanted to follow up...

I had a hunch so a few days ago I removed the Unraid Connect plugin.

Since then, I haven't had an issue. Usually it would have frozen a couple times since then.

Every other time that I've had freezing issues over the years and versions (both plugin and Unraid), it has always been due to the Unraid Connect plugin, so I remembered that and looks like that was probably it once again.

And on a side note, for a couple months, I have been having this other small issue where my wattage usage has jumped from about 80w idle to 130w idle.

I thought it was because I added an HBA LSI and one more drive.

However, since I removed Unraid Connect, it has gone back down to 80w~ish idle. So maybe a coincidence, maybe not.

I can't use Tailscale at work so absolutely need Unraid Connect unfortunately so not sure what to do since it inevitably ends up freezing my server every single time.

But anyway, wanted to update everyone!

Another follow-up.

Just now it froze out of nowhere again, so I guess it wasn't Unraid Connect, although this is the longest it has lasted since it started having the issue.

Here's a new diagnostic.

Regarding the things @JorgeB said since I forgot to last time...

I have 64GB of RAM and it never really gets more than about halfway.

This last time it froze, I was directly messing around in the dashboard looking at various plugin settings and the dashboard ran fine. No lag. And my qbit container wasn't laggy either. Within a few minutes, it froze.

I actually do pin all my cores, or should I say pin them to all but cores 0 and 1.

I set the fuse Descriptors to max (6556848 - it was at 40xxx) and ran touch /boot/config/fastusr and rebooted.

I'll see what happens!

devante-nas-diagnostics-20251127-2223.zip

Edited November 28, 2025Nov 28 by DevanteWeary

Update: it just froze again.

I'm at a loss here. Pretty sure this is gonna fry my drives.

devante-nas-diagnostics-20251129-1614.zip

Still seeing the same messages:

Nov 29 15:38:38 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 977691 exited on signal 9 (SIGKILL) after 81.167731 seconds from start

Nov 29 15:38:51 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 990270 exited on signal 9 (SIGKILL) after 33.836279 seconds from start

Nov 29 15:38:53 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 990271 exited on signal 9 (SIGKILL) after 36.174163 seconds from start

Nov 29 15:38:55 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 990272 exited on signal 9 (SIGKILL) after 37.674269 seconds from start

Nov 29 15:39:04 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 998155 exited on signal 9 (SIGKILL) after 20.024278 seconds from start

Nov 29 15:39:07 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999205 exited on signal 9 (SIGKILL) after 15.197533 seconds from start

Nov 29 15:39:39 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999259 exited on signal 9 (SIGKILL) after 17.435365 seconds from start

Nov 29 15:39:57 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999320 exited on signal 9 (SIGKILL) after 54.904236 seconds from start

Nov 29 15:40:20 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999441 exited on signal 9 (SIGKILL) after 55.886908 seconds from start

Nov 29 15:40:38 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999529 exited on signal 9 (SIGKILL) after 83.719493 seconds from start

Nov 29 15:40:40 Devante-NAS php-fpm[15467]: [WARNING] [pool www] child 999701 exited on signal 9 (SIGKILL) after 56.749394 seconds from start

Yeah it's just my server never really gets more than half of its RAM used. (64GB total, around 32GB is used).

I just noticed that I had SOME containers pinned and some not pinned.

Probably a result of pinning a bunch one time, and then installing more later on.

I'll go back and pin everything so that they're not touching cores 0 and 1 and see what happens.

You can also try running with just half of the containers; if the same, try the other half, then keep drilling down.

Just a follow up on the situation: it's still happening.

I've tried:

• Different RAM

• Updating BIOS

• Updating firmware of HBA LSI card.

• Disabling VM service.

• Shutting off every container except Plex

• Setting max fuse descriptors.

• Safe mode with nothing running for a day I think, it didn't freeze - also tried safe mode with Plex running but it wouldn't connect externally)

• Other stuff I'm sure I'm forgetting.

Not only does it happen, it started getting worse. Happening like every 30 minutes one day.

To add to that, pressing the power button stopped working correctly.

Unraid would get stuck "collecting diagnostic data" or whatever indefinitely during shutdown. So I've hard to hard power down. My poor drives.

Last try, I ran only Plex for 3 days and it was fine.

Then I turned on my streaming and download stack (The *arrs, qbittorrent, etc) and it worked for another three days and just locked up right now.

Luckily the power button worked.

I still have yet to try:

• Removing all plugins. (trying to figure out how to do this without losing my plugin settings)

• Running normally even without Plex for a few days.

I'm just really at a lost. I'll try the two above of course.

Went from the perfect Unraid system for a couple years to this seemingly over night.

And I wouldn't mind so much if not for I'm destroying my hard drives.

Anyway, just updating.

This diagnostics is from when I happened to be looking and saw my HTOP window go away (which indicates it's crashing) and verified that I couldn't get to the dashboard so pressed the power button. I caught it in time for it to power down properly.

Memory usage was hovering around 20GB out of 32GB last I looked (normally I have 64GB but I'm trying different sticks).

devante-nas-diagnostics-20260111-1429.zip

Edited January 11Jan 11 by DevanteWeary

Syslog just has these, and then it stops recording more due to the spam:

Jan 11 14:15:00 Devante-NAS vnstatd[3613]: Interface "veth23f862f" disabled.

Jan 11 14:15:00 Devante-NAS vnstatd[3613]: Interface "veth23f52cb" disabled.

Jan 11 14:15:00 Devante-NAS vnstatd[3613]: Interface "veth23f1f96" disabled.

These are from the dwdvm plugin; I recommend uninstalling that while you troubleshoot at least to avoid the log spam.

Just found this from the reddit thread where you posted a link over the weekend. I know you said you tried changing the ram, but have you run memtest? If you're having inconsistent freezes maybe leave the tests running for a few hours (or overnight). It could be somewhere else in the memory subsystem rather than the RAM stick specifically.

9 hours ago, spyder said:

Just found this from the reddit thread where you posted a link over the weekend. I know you said you tried changing the ram, but have you run memtest? If you're having inconsistent freezes maybe leave the tests running for a few hours (or overnight). It could be somewhere else in the memory subsystem rather than the RAM stick specifically.

Oh yeah, I ran a memtest for over 24 hours and it showed everything fine.

Coincidentally, it JUST froze about 5 minutes ago.

CLI is still running, though, albeit extremely slowly. So hopefully I can stop the pre-clear that was running on a new 20TB I just put in yesterday.

I thought I had it narrowed down to either Homepage or binhex-Krusader but it just happened as I was loading stats in Prowlarr.

So I'm back to having no idea.

About ready to give it all up since this thing is probably killing my drives each forced power off.

6 minutes ago, DevanteWeary said:

CLI is still running, though

What do you get from command line with this?

df -h /

23 minutes ago, trurl said:

What do you get from command line with this?

df -h /

DOh sorry, I had already issued a reboot command before reading that.

Now it's just sitting at "rc.local_shutdown: Active pids left on /mnt/*" and probably will be until I can get home to force power it off.

I'll remember to run that next time it happens and report back though!

edit: Now it's stuck on "Generating diagnostics..." - Sometimes it does actually get past the active pids message but will 100% be stuck at this for until I force power off.

Edited February 25Feb 25 by DevanteWeary

On 2/25/2026 at 12:45 PM, trurl said:

What do you get from command line with this?

df -h /

Hey again.

It froze again today. Lasted about 9 days. I still had access to the CLI via PiKVM so of course I typed reboot and then immediately remembered you asking this. Doh...

Well anyway so it did the exact same thing. Froze at "open pids on /mnt/*" or something, so I pressed the physical power button and it restarted the shutdown process, got stuck there for a while, then kept going until it got stuck on Generating Diagnostics for over an hour. So I forced shut down once again.

Well I don't know if it's helpful, but once I got booted it up, I ran your command:

Filesystem Size Used Avail Use% Mounted on

rootfs 16G 1.1G 15G 7% /

The only thing I was actively doing at the time was I went to Sonarr, I went to a show, I clicked on Interactive Search, then it just stayed there doing a little animation for much longer than normal.

I just let it sit and eventually I noticed the server locked up again.

I do remember one other time a couple of months ago, it locked up when I did a search from Prowlarr.

Anyway, just some more info.

By the way, all this wouldn't be AS big a deal except I have to force it.

Any tips on having it not get stuck on the generating diagnostic part?

Thanks!~

devante-nas-diagnostics-20260308-1811.zip

Edited March 9Mar 9 by DevanteWeary

OK here's a new lockup.

This one is slightly different.

It locked up at about 9:45PM. Then after a couple of minutes, it started working again.

Then it locked up again at 10:00PM and didn't come back. I had to "Magic SysRq" emergency reboot using my PiKVM.

Was hoping having the times and two right next to each other might bring out some new info.

Thank you!

devante-nas-diagnostics-20260406-2233.zip

Apr 6 22:24:51 Devante-NAS php-fpm[15891]: [WARNING] [pool www] child 3558764 exited on signal 9 (SIGKILL) after 13.065194 seconds from start

Apr 6 22:24:53 Devante-NAS php-fpm[15891]: [WARNING] [pool www] child 3558765 exited on signal 9 (SIGKILL) after 15.045978 seconds from start

In my experience, these errors can be the result of the server being close to exhausting the memory, GUI can become extremely slow, like 1 minute to open the dashboard, try limiting the memory for VMs/docker services, or adding a little more RAM.

It could also be one or more containers hogging the CPU, try pinning only some cores to them, and leave cores 0/1 available for Unraid.

Also, recommend trying a couple of other things, go to Settings - Global share settings and set the Number of fuse File Descriptors to the max, and enable this:

https://docs.unraid.net/unraid-os/release-notes/7.0.0/#excessive-flash-drive-activity-slows-the-system-down

On 4/6/2026 at 11:56 PM, JorgeB said:

Also, recommend trying a couple of other things, go to Settings - Global share settings and set the Number of fuse File Descriptors to the max, and enable this:

https://docs.unraid.net/unraid-os/release-notes/7.0.0/#excessive-flash-drive-activity-slows-the-system-down

OK will do.

I actually do have all my containers set not to use 0/1 cores.

I remember you mentioning I should increase the file descriptors to 6556848 before so I did that and it's currently set to that.

However the max says like... half that ha. So maybe I'll lower it to the max.

Also for reference, this issue started when I had my other RAM sticks in: 64GB (which I keep meaning to move back to).

Just a note: I'm sort of kind of leaning toward maybe... binhex-Krusader might be the culprit?

Because so far it almost seems to last forever until I enable Krusader container. Then it'll lock up within a day or two.

Currently in the process of trying to eliminate that as a cause!

On 4/9/2026 at 8:07 PM, DevanteWeary said:

Just a note: I'm sort of kind of leaning toward maybe... binhex-Krusader might be the culprit?

Because so far it almost seems to last forever until I enable Krusader container. Then it'll lock up within a day or two.

Currently in the process of trying to eliminate that as a cause!

If I remember correctly, Krusader can get bloated and increase in size, especially if it has things like trash recovery or custom locations configured.

As it is only a basic utility, nothing valuable would be lost by deleting its appdata, removing the container, then reinstalling it fresh.

Update

Well guys, I don't wanna jinx it but I'm pretty sure I found the issue.

You guys ready for this one?

tldr; The stats in Prowlarr being called caused the RAM to max out.

The culprit: the Prowlarr widget in the Homepage app/container. And only when actually bringing up the Homepage UI.

So how did I get to that? Well over the months, I've turned on containers one by one and let it run. All the other times it locked up, I don't remember exactly what was running or what I was doing but I have had a feeling it was either Krusader or Homepage for months. If you see, I mentioned this on Feb. 25.

Well a month or so ago I was talking with a friend about Homepage and started it to show my friend and the server locked up.

So then I turned everything BUT Homepage on and it was fine. Then I started each app for which there was a Homepage widget until I started Prowlarr and it instantly locked up again.

So then I load ONLY Prowlarr and it's fine. I click around and as soon as I click on the stats page, it spikes the RAM and locked up once again.

My Prowlarr settings were set to never delete any history and so I had millions of queries from the past couple of years. Once I set it down to like two weeks, it still spikes the RAM if I go to stats but not as much (4GB vs the 20+ GB from before).

I removed the Prowlarr widget from Homepage and turned everything else back on and so far it has been fine for a few weeks.

One little widget caused me so much pain ha. I'm sure the widget was triggered whatever going to the stats tab in Prowlarr does.

I think one thing that was making it harder was all the SIGTERM errors I've been getting.

I don't think they're related at all actually. I think they're something else because I'm still getting them and it's still causing my webUI to lock up for a minute or two but the CPU and RAM both are at normal levels when it happens. Grok says it could be my disk IO wait times. I noticed usually when that happens, the busy percentage jumps from under 100% to like over 400%. I'm not sure how to tackle that issue though. I guess I'm just glad I found the original issue!

THanks for everyone who tried to help!