Could I get some explanations regarding the FreeNAS plugin?

[Vitz 1]

I'm currently running Emby 4.4.2.0 as a pluginv2 on FreeNAS 11.3 U3.2. It's been running all right ever since I set it up last year, but there are significant problems. For one, Emby doesn't appear to be restricted by its jail. Instead of Mono running inside the jail, top in the main shell shows me it's running on the core system, under the user ID 989. Is this normal? The main issue here is that Mono also has a memory leak that requires me to restart the Emby jail ~weekly (something I've been trying to automate but I can't figure out the proper Cron job). Messing about with Mono updates to fix this in a jail is one thing, but seeing as it's running on the main system I don't feel comfortable doing that. On top of this, I just had a user trying resume a video (eventually successfully) but absolutely hammering my server in the process, despite Emby's transcoding thread count being set to half of what the system contains. This task (ffmpeg), according to top, was also running on the core system instead of inside the jail.

Because most of the things that matter seem to actually run outside of Emby's jail, I also can't utilise BSD's built-in rctl function in order to limit resources, because it's very ill-advised to actually mess around with the FreeNAS configuration files manually.

Can someone provide some insight as to why this is designed in such a way? I'm obviously not the most experienced user and I'd love to understand more about the inner workings, and hopefully fix the problems I'm experiencing in the process. I've included the Emby server log, with some censorship as to not reveal my server address.

I hope I'm not just being an idiot here who managed to colossally screw up their initial install, but please let me know if I am.

embyserver.txt

Edited August 14, 2020 by Vitz

[Luke 37025]

Hi, the only reason we use mono on freebsd is because the .Net core runtime does not support it yet. Supposedly later this year with version 5 it will, and that will make emby server much lighter on its feet on freebsd.

Regarding running mono inside or outside of the jail, to be honest I'm not really sure.

[MRobi 159]

What you're seeing when you issue a top command isn't saying that it's running outside of its jail, in fact that should be an "impossibility".

The top command displays what cpu processes are running as well as memory stats. In fact, it should show the "PID" running it which stands for program id. You can then verify that PID matches the PID inside your emby jail. Even though these processes are running inside a jail, they're still going to take system resources when running, and anytime those resources are being used they should show up when you run top from shell.

I'd be looking at this rebooting emby on the weekly thing though because that's not normal. First thing, I'd start by updating to 4.4.3.0 before trying to troubleshoot an outdated version. There was another user on here a few weeks back, who also had 4.4.2.0 who was saying after a few days Emby would be consuming 30+Gb of RAM which is unusual. I've been on 4.4.3.0 since almost the day it came out and haven't seen any signs of memory leaks or high RAM usage. 

[Vitz 1]

On 15/08/2020 at 23:59, MRobi said:

What you're seeing when you issue a top command isn't saying that it's running outside of its jail, in fact that should be an "impossibility".

The top command displays what cpu processes are running as well as memory stats. In fact, it should show the "PID" running it which stands for program id. You can then verify that PID matches the PID inside your emby jail. Even though these processes are running inside a jail, they're still going to take system resources when running, and anytime those resources are being used they should show up when you run top from shell.

I'd be looking at this rebooting emby on the weekly thing though because that's not normal. First thing, I'd start by updating to 4.4.3.0 before trying to troubleshoot an outdated version. There was another user on here a few weeks back, who also had 4.4.2.0 who was saying after a few days Emby would be consuming 30+Gb of RAM which is unusual. I've been on 4.4.3.0 since almost the day it came out and haven't seen any signs of memory leaks or high RAM usage. 

Thank you for clearing up my confusion regarding the running processes.

I agree needing to restart Emby every week isn't normal, but I don't really know how to fix it. It's been a problem since the day I installed it (though it took me a while to identify), and updates to date haven't changed anything in that respect. Speaking of updating, I tried to grab Emby 4.4.3.0 but FreeNAS tells me there are no updates available for it, despite the Plugins page saying the latest version is, in fact, 4.4.3.0. Peculiar. I think I might just wait until .NET Core has been implemented and start from scratch with Emby in an actual jail, not a plugin. In the meantime everything works fine, I just need to remember to restart the plugin weekly or so.

On 15/08/2020 at 03:21, Luke said:

Hi, the only reason we use mono on freebsd is because the .Net core runtime does not support it yet. Supposedly later this year with version 5 it will, and that will make emby server much lighter on its feet on freebsd.

Regarding running mono inside or outside of the jail, to be honest I'm not really sure.

That's good news. Thank you for replying. Would this also mean real-time monitoring would begin to function?

Edited September 3, 2020 by Vitz

[Luke 37025]

Just now, Vitz said:

 

That's good news. Thank you for replying. Would this also mean real-time monitoring would begin to function?

@Vitz I honestly can't say. In the upcoming .NET 5 release, Microsoft wants to support FreeBSD, but they are mostly relying on community contributions in order to actually achieve it.  It's possible the real-time monitor for BSD will just be ported in from mono, or left unimplemented, or in some other state of only partially working (which is historically how it's been with the mono runtime).

Having said that, just being able to run with .NET core at all as opposed to mono would still be a huge win, even if some of the smaller supporting features still don't function.

[Vitz 1]

Got it. Thanks.