Running unRAID v6.1.9

Server memory: 4GB (Usage hovers around 40 to 50% most of the time during normal operation)

------------

 

 

As per this thread:  https://lime-technology.com/forum/index.php?topic=39510.0

 

I am now experiencing the exact same problem all of a sudden. 

 

I'm also seeing this with SABnzbd.

 

I've been running SABnzbd in a docker container in unRAID since the very first unRAID BETA that supported it, and I've never had this issue, but in the last 2 weeks it's started happening constantly.

 

I now have 2 different SABnzbd docker containers deployed, from 2 different sources, and both are doing the same thing.

 

SABnzbd will suddenly become non-responsive, as in the web UI will not respond at all. And then if I try to do anything with it from inside the unRAID UI, the unRAID UI also becomes non-responsive.

 

Remoting into the unRAID box and issuing docker STOP or KILL commands on the container in question does nothing and the only way to get the unRAID UI to become responsive again is to issue a KILL -9 against Docker itself.

 

Even more disturbing is that once this happens, I cannot get SABnzbd to fire up again without restarting the entire server. I can kill Docker itself from the command line, then bring Docker back up and get all my other Docker containers back up, but even after restarting Docker like that I cannot get the SABnzbd container to fire up properly again and respond. I have to restart the server.

 

Needless to say, this is extremely frustrating and not a particularly efficient way to work.

 

It's also concerning that this has been looked at before and it looks like it was sorted out, but now it seems to be back again.

 

Server info:

 

CPU: AMD Athlon II Neo N36L Dual-Core @ 1300

HVM: Enabled

IOMMU: Disabled

Cache: 256 kB, 2048 kB

Memory: 4096 MB (max. installable capacity 8 GB)

Network: eth0: 1000Mb/s - Full Duplex

Kernel: Linux 4.1.18-unRAID x86_64

It's not clear from your post that you are aware there are numerous versions since 6.1.9, with numerous fixes.  The thread you pointed too has been marked 'Solved' because the fixes in the later unRAID versions appear to fix the various issues with this behavior.  You say it's a problem that's come back, but I don't understand why you think that.  Have you tried the latest version of unRAID?

As much as people like to think that a docker container is completely isolated from the rest of the system, truth be told they are not in one certain respect.

 

Any docker app can completely chew up all of the CPU resources should it go completely haywire.  (SabNZBD is notorious for this whether running as a docker or separately on a Windows system -> use nzbGet instead - it actually works).  This isn't a docker issue per se, but is a SabNZBD / python issue.

 

The solution is to always limit the CPU resources of any / all apps  so that if they do go nuts (and say wind up in an infinite loop and never give up the CPU) that there is always room for other apps to operate normally.

 

See here: Get Fancy with Docker and CPU Pinning. 

 

Pinning is almost expected to be done when running VMs for best performance / stability of the system as a whole, and docker is no exception -> especially when running SabNZBD