Michael_P

Hard shutdowns/reboots are usually the power supply, especially if it only happens under load. Next on the list is the CPU either overheating or failing, then the motherboard.

have you seen some of the signatures on here lol, i have 'em turned off for a reason

Your server is running out of memory and the reaper is killing the docker service because it sees it as the highest consumer. Make sure your VM isn't over-provisioned and verify that all of your containers and are properly configured and that things like emby are not transcoding to RAM. Reboot to clear the log so FCP stops warning you. If it happens again after you've fixed your conatiner/VM, post the output of ps -auxf taking care to remove any passwords if necessary

Parity increases redundancy, not safety. Backups for important data trumps adding additional parity drives. So IMHO if you're considering a second parity drive for 'safety', I'd just use it for backing up instead. +1 for if your backup strategy is already on point, just chuck it into the array for extra space.

I had to ask ChatGPT to summarize your literal wall of text This script is what I use to backup between servers

At around 10am yesterday one of your containers started spawning a lot of chrome processes and ran the host OOM with the last entry in your log at around 1037. Figure out which container it is (ps -auxf) then fix its config or limit the RAM to the container. When you've done that, reboot to clear the log so FCP stops warning you

Looks like a markup error when there's an apostrophe

Redundancy doesn't mean no data loss, it means you can keep working if you lose two disks at the same time. There's plenty of ways to lose data without a hardware failure. Rather than worrying about a file system, think about backing up your important stuff so a hardware failure, or multiple hardware failures isn't catastrophic.

For desktop clients - UrBackup For phones - Nextcloud For the server and the important stuff above - another Unraid server with an rsync script And another copy of the important stuff manually to cold external hard drives

Bump the time up an hour and see if the OOM follows it

You shouldn't need a swap file, you have plenty of RAM for what you're doing - you just have to make sure your container's folders are correctly mapped to disk, and they are limited to whatever arbitrary amount you want to set. jellyfin and immich are pretty big hogs if not configured correctly (watch a couple movies at the same time and bang, OOM) - HA can get wonky too, but I don't use it so I can't help you there. From the log in your OP, on the 13th and 18th the host ran OOM at about the same time - 0337 and 0343 respectively - so you can also see if there's a scheduled process in any of your containers kicking off around that time (maybe every 5 days, too?)

Looks like a case of just too much going on at once and the reaper just pulled Docker from the top of the list - if it happens again, you can limit the RAM available to the containers or change their config so any file storage is on disk instead of RAM (especially jellyfin). Reboot if you haven't already to clear the log

What I mean is I wouldn't trust it with any irreplaceable data, anyway. Might get some more mileage out of it for storing backups and such

errors were all in a row, but i'd still relegate it to backup duty Pending Defects log (GP Log 0x0c) Index LBA Hours 0 8592654424 54379 1 8592654425 54379 2 8592654426 54379 3 8592654427 54379 4 8592654428 54379 5 8592654429 54379 6 8592654430 54379 7 8592654431 54379 8 8592654440 54399 9 8592654441 54399 10 8592654442 54399 11 8592654443 54399 12 8592654444 54399 13 8592654445 54399 14 8592654446 54399 15 8592654447 54399

Looks like Jellyfin tipped the scale a little too deep and ran the host OOM on the 27th and 28th, if it happens again you can change the config so it's not using RAM as cache. Reboot to clear the log so FCP stops warning you. Also, autofan is spamming your log, you ought to change the logging level to clean it up a bit.

Reliable and smooth at doing what? They're different operating systems that serve different purposes. I'm not even sure what you mean with windows screwing up Unraid - Unraid can host a Windows VM, but an update to Windows can't screw with the host. And you don't "plug an unraid USB into a Windows machine", it's either an Unraid Machine or a Windows Machine - it's not both at the same time

Whatever it's trying to do in RAM, maybe can be done to disk

That's what's being reported - the reaper is killing it when it exceeds the limit. Increase the RAM available to the container or put it on a diet. Make sure you reboot to clear the log so FCP won't trigger on it again

Do you have a memory limit set for your Radarr container?

Did a prankster hide one of those beepers in or near it

post the output of ps -auxf taking care to remove any passwords if you have VPN containers and the like

ps -auxf will tell you what's spawning what and the resources it's using, can be helpful tracking down repeat offenders.

It might actually just be docker killing it (doing it right for once), hasn't happened in a couple days so I wouldn't worry about it too much - if you have free RAM to play with, allocate a bit more to it or put qbittorrent on a diet so it's not using as much.

No, your host is running out of memory and killing what it thinks is using the most memory - and that it's continuously killing qbittorrent, that would be the likely suspect. Doesn't look like it from the logs but are you running any other containers?

May 14 04:48:11 Astaroth kernel: Memory cgroup out of memory: Killed process 3887080 (qbittorrent-nox) total-vm:2118364kB, anon-rss:2074044kB, file-rss:88kB, shmem-rss:0kB, UID:99 pgtables:4180kB oom_score_adj:0 it was repeatedly running OOM and killing qbittorent from when your logs started on May 11th until May 14th