"fatal error: runtime: out of memory runtime stack" when trying to access the docker plugin in OMV. Rock64

Hi all,

Currently using OMV4 on a Rock64 1GB board. So to start, yes I know I only have 1GB of RAM, however OMV is showing memory usage of <60%.

I'm usually running a few docker containers (emby, sonarr, jackett, duckdns, portainer, transmission), and they will all start off fine, however after a few hours I will no longer be able to go into the docker plugin without it throwing an error. Also if I try and start/stop any of them in Portainer (or view container stats) I'll get a similar error (even trying to stop one!).

The running containers all still work perfectly fine when using them, however trying to manage any of them or start/stop new ones that gives me errors.

If I look at them after a couple of hours (before I have issues) none of them seem to be using excessive amounts of RAM... Including cache, emby is ~100MB, sonarr ~100MB, jackett ~100MB, portainer <20MB, transmission ~50MB, duckdns <5MB. In total that's less than 400MB.

I'm not sure what the memory footprint of OMV itself is, or the couple of plugins I have enabled (OpenVPN, docker, SMB sharing, shellinabox), but looking at the System Information tab of OMV shows <60% memory usage.

Am I missing something, or should I expect this? Is OMV not reporting 'real' memory usage? If there's some 'invisible' memory reservations, shouldn't it be grabbing some of this when it needs it? What about swap space? (Shouldn't it use that rather than just failing..?).

Forgive my beginner ignorance about everything, I'm not a linux expert and have only been using OMV for a few months now!

I've attached a screenshot of the System Information page of OMV, and below is the full error that appears when trying to access the Docker plugin page in OMV.

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; docker images 2>&1' with exit code '2': fatal error: runtime: out of memory runtime stack: runtime.throw(0xac644d08, 0x16) /usr/local/go/src/runtime/panic.go:616 +0x64 fp=0xffb99d08 sp=0xffb99cfc pc=0xab520860 runtime.sysMap(0xb2200000, 0xbe00000, 0xab501401, 0xad66de60) /usr/local/go/src/runtime/mem_linux.go:227 +0x124 fp=0xffb99d34 sp=0xffb99d08 pc=0xab507284 runtime.(*mheap).mapBits(0xad6602d8, 0xbe000000) /usr/local/go/src/runtime/mbitmap.go:160 +0x98 fp=0xffb99d4c sp=0xffb99d34 pc=0xab503bf8 runtime.(*mheap).setArenaUsed(0xad6602d8, 0xbe000000, 0xade00000) /usr/local/go/src/runtime/mheap.go:545 +0x24 fp=0xffb99d58 sp=0xffb99d4c pc=0xab51644c runtime.(*mheap).init(0xad6602d8, 0xade00000, 0x200000) /usr/local/go/src/runtime/mheap.go:530 +0x44c fp=0xffb99d6c sp=0xffb99d58 pc=0xab516054 runtime.mallocinit() /usr/local/go/src/runtime/malloc.go:392 +0x218 fp=0xffb99db0 sp=0xffb99d6c pc=0xab5016d8 runtime.schedinit() /usr/local/go/src/runtime/proc.go:490 +0x68 fp=0xffb99de0 sp=0xffb99db0 pc=0xab5233d4 runtime.rt0_go(0xffb99f74, 0x2, 0xab54bf18, 0xf727d000, 0xaaaaaaab, 0xa1d64080, 0xa97bbadd, 0x130, 0x0, 0xac623251, ...) /usr/local/go/src/runtime/asm_arm.s:159 +0x84 fp=0xffb99e20 sp=0xffb99de0 pc=0xab54bfac

Thanks both for your replies. I suspect I may just be being naive about linux memory usage behaviours, but hoping someone on here might have some ideas about why it's causing errors rather than just becoming slow (using more disk swap space).

Zitat von tkaiser

Since you're running on ARM can you please provide output from sudo armbianmonitor -u after such an occurrence?

That command didn't work (says armbianmonitor: command not found), but I tried 'top' to view memory stats. It does indeed look like including the buffer/cache usage it's only leaving <15MB 'free' (screenshot of that info along with the processes listed as using resources). I also tried the meminfo command which shows the second screenshot.

However, I gather than Linux will try and use up as much memory as possible to speed up apps. My understanding though is that it should then relinquish some of that memory when you need to start up something else, or do something new...
Currently showing ~120MB 'available', which I would assume should be available for this sort of purpose?

Given the above, it may explain why I can't start new docker containers (less so why I can't start a container I know takes <10MB total), however I don't understand why it would throw that error just trying to go into the docker plugin in OMV (or e.g. stopping a running container in Portainer, giving a similar error).

Thanks! That makes sense if I don't have any swap configured... I'll try that image when I get a chance. Hopefully I can backup and restore my settings...? I'll give it a go using the guides on here anyway.

Serves me right for not being more careful with what image I use! I thuought I got it over on the ayufan github, but now I can't seem to find it so guess I'm wrong.

Thanks again for the help guys.