Michael_P

Without the previous logs it's not possible to tell if the OOM is related to the crashes, but it's probably not. In this case Jellyfin was probably transcoding and ran the host OOM. You can re-boot to clear the log so FCP stop warning you about it, and if it happens again you can reconfigure it to transcode to disk or limit the RAM allowed to the container.

This is the likely answer even if you're offloading ML.

Looks like on the 15th of Nov and on the 14th of Dec a python process ran away, if you enable the advanced view on the docker tab you can see if 9c26809c57e9 matches any of your containers - it's the one that spawned the process. Once you've fixed it, reboot to clear the log so FCP stops warning you.

Looks like whatever you or your server was doing back on the 11th around 1752 had a java process run away with all of the RAM. If you were doing something at that time (transcodes, immich. whatever is creating all of those docker-proxy processes, etc) you can ignore it, and if it keeps happening you can investigate which one needs to be put on a diet. You can reboot to clear the log so FCP stops warning you.

Looks like you have a pretty low RAM system, from a modern standpoint, so whatever the system was doing around 2340 to around 2350 on the 7th ran itself OOM (which on the last event the kernel killed docker to save itself). You can add more RAM to alleviate the problem, or limit the RAM available to your services. You will need to reboot to clear the log so FCP stop warning you, too.

This

Your system didn't OOM, your nvidia card fell over and FCP saw 'out of memory' and generated the warning - try updating the driver and system BIOS. Then, you can reboot to clear the log so FCP stops warning you Dec 1 20:15:57 227CS kernel: NVRM: nvCheckOkFailedNoLog: Check failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from _memdescAllocInternal(pMemDesc) @ mem_desc.c:1359 Dec 1 20:15:57 227CS kernel: NVRM: nvCheckOkFailedNoLog: Check failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from rmStatus @ system_mem.c:354 Dec 1 20:15:57 227CS kernel: NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from pRmApi->Alloc(pRmApi, device->session->handle, isSystemMemory ? device->handle : device->subhandle, &physHandle, isSystemMemory ? NV01_MEMORY_SYSTEM : NV01_MEMORY_LOCAL_USER, &memAllocParams, sizeof(memAllocParams)) @ nv_gpu_ops.c:4922

Probably, since it was einstein that was being killed repeatedly back on the 29th and 30th. Bad memory wouldn't cause an OOM, only using too much RAM will. Fix whatever the container is doing, or limit the memory available to the container itself, and reboot to clear the log.

Sort of, while it was the nvidia card falling over, it didn't cause your system to go OOM (it would take and awful lot of log to fill up available RAM and knock the host over). AI is great, but it only ever gets it sort of correct. FCP saw the string 'out of memory' in the log and spit out the warning. Nov 30 05:53:56 Tower kernel: NVRM: nvCheckOkFailedNoLog: Check failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from _memdescAllocInternal(pMemDesc) @ mem_desc.c:1359You need to update the GPU driver and/or motherboard BIOS - if that fails, set it to use a lower PCIE generation in BIOS to see if the errors stop

Looks like plex pushed it over, limit the memory allowed to the container or reconfigure to cache to disk - reboot to clear the log so FCP stop warning you You should also try to figure out what's going on here, it's flooding the log Nov 30 09:09:46 hoth avahi-daemon[2760]: Registering new address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0.*. Nov 30 09:16:46 hoth avahi-daemon[2760]: Withdrawing address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0. Nov 30 09:17:05 hoth avahi-daemon[2760]: Registering new address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0.*. Nov 30 09:26:51 hoth avahi-daemon[2760]: Withdrawing address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0. Nov 30 09:28:06 hoth avahi-daemon[2760]: Registering new address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0.*. Nov 30 09:35:28 hoth avahi-daemon[2760]: Withdrawing address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0. Nov 30 09:36:40 hoth avahi-daemon[2760]: Registering new address record for fdf9:beec:fb34:6c40:XXXX:XXXX:XXXX:f1f9 on br0.*.

Looks like maybe you're immich container is pushing your server over the edge, you'll need to add more RAM to the server or limit the amount of RAM your services and VM is allowed. Reboot to clear the log so FCP stops warning you

You've got it right - make sure it's actually transcoding to disk, and if all else fails you can limit the memory allowed to the container. It could be choking on a particular file, too - judging by how it spikes rapidly (I've had that happen with Plex as well). So you can investigate that angle by narrowing down any recent additions to the library

RIP

Sounds like you're recruiting a mule lol. Pro tip: never carry a package internationally given to you by a stranger.

Looks like both events happened back on the 3rd, and it killed your VM both times. If your Plex service is transcoding to RAM, that may have had something to do with it. Reboot to clear the logs, and if it happens again you can try putting some of your services on a diet

Try reposting your diagnostic file

Mirror and post your syslog or anything would just be a WAG

You need more RAM, 6GB is too little for whatever you're doing - it's killing off smbd which is causing your file browsing issues. Add RAM or try the swap file plugin

Looks like zoneminder, if it keeps happening you can try to limit its memory usage, add more RAM, or put other services on a diet.

The folks behind Blue Iris have an active, bordering on unreasonable, dislike for anything Reolink, so if you need support you're out of luck there. If you're set on that brand of camera, leave BI off of your list. I have a dozen of them and they work fine, but you're on your own with them.

No idea, I watched my son play it once and couldn't see the point of it

Map any cache directories it's using to a disk, /tmp is a common one. If it's a game server, you'll probably just need to throw more RAM at it, turn off other services while it's running, or use the swap plugin

The game itself is not free, you can get a free trial but you still have to pay for it if you intend to keep playing

Run memtest and/or remove modules until you find the bad stick

Looks like whatever 'TowerServer-Lin' is has run the host OOM twice in your logs, once on the 26th and again yesterday - if it keeps happening you can limit the memory allowed to the container or change its config so that it's not storing data in RAM