Jump to content


Photo

Problems running Emby in a LinuxContainer

lxc

  • Please log in to reply
12 replies to this topic

#1 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 04 April 2016 - 10:11 AM

So I've been running Emby in a virtual machine with OpenMediaVault for a while now.

Now I'm migrating everything to LXC so I get more space and better performance.

 

I now wanted to install and run Emby within a container (LXC not Docker), with a Ubuntu 14.04 container I've had problems since Emby didn't find ffmpeg.

Because of that I installed it to a Ubuntu 15.04 container and I also installed the latest ffmpeg from that repo, even though it could now find ffmpeg and ffprobe, after scanning the library emby would randomly just crash.

The last exception it throws was a NullPointerException because something went wrong with ffprobe and Object reference not set to an instance of an object

 

Then I used a container with Arch where it seemed to be running okay but then again after a few minutes Emby just crashed with the same error as above. Sudo was installed, the emby user had all the permissions he and Emby ran fine, there is no indication what causes this, there is no error prior to the exception and the file that gets scanned is always random, so it's not my files that cause this... I also installed mediainfo.

 

I don't have the log at the moment because I killed the container again after deciding I don't want Emby if I can't run it in a container. Now I reconsidered my decision and thought maybe someone here can help me. But as soon as I get home I'm going to install a new container with Emby and attach the logs.

As soon as I get home I'll install a new container with Emby and attach the logs.


Edited by shawly, 04 April 2016 - 10:15 AM.


#2 hurricanehrndz OFFLINE  

hurricanehrndz

    Advanced Member

  • Developers
  • 1249 posts
  • Local time: 04:43 PM

Posted 05 April 2016 - 12:34 PM

So I've been running Emby in a virtual machine with OpenMediaVault for a while now.

Now I'm migrating everything to LXC so I get more space and better performance.

 

I now wanted to install and run Emby within a container (LXC not Docker), with a Ubuntu 14.04 container I've had problems since Emby didn't find ffmpeg.

Because of that I installed it to a Ubuntu 15.04 container and I also installed the latest ffmpeg from that repo, even though it could now find ffmpeg and ffprobe, after scanning the library emby would randomly just crash.

The last exception it throws was a NullPointerException because something went wrong with ffprobe and Object reference not set to an instance of an object

 

Then I used a container with Arch where it seemed to be running okay but then again after a few minutes Emby just crashed with the same error as above. Sudo was installed, the emby user had all the permissions he and Emby ran fine, there is no indication what causes this, there is no error prior to the exception and the file that gets scanned is always random, so it's not my files that cause this... I also installed mediainfo.

 

I don't have the log at the moment because I killed the container again after deciding I don't want Emby if I can't run it in a container. Now I reconsidered my decision and thought maybe someone here can help me. But as soon as I get home I'm going to install a new container with Emby and attach the logs.

As soon as I get home I'll install a new container with Emby and attach the logs.

Emby should run fine within any containerized environment. As you can see we have a docker image that works perfectly without any issues.  For a containerized environment we recommend you use the static builds of ffmpeg. Also emby does not depend on ffmpeg and ffrpobe, if it does not find it on boot it should download ffmpeg and ffprobe itself.



#3 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 06 April 2016 - 07:26 AM

Well it does download them. But Emby doesn't use them within the start parameters. When ffmpeg and ffprobe are located within the /usr/bin folder it adds -ffmpeg /usr/bin/ffmpeg to it's start parameters, which it doesn't if it downloads the binaries itself, is this correct?
 
Even though Emby doesn't crash because it doesn't find the binaries, it crashes randomly it seems, but the last exception that is thrown is caused by ffmpeg, I don't know if that's the reason why Emby crashes...
 
I'll now setup a Debian container, just to see how it behaves on Debian, since the Emby that was running on OMV worked fine.
 
Edit: Okay it also crashes in the Debian container, log attached
This time I didn't install ffmpeg btw. I also didn't install any plugins, I just installed Emby, set up my paths and scanned the library, that's it...
 

Edit2: I've let the Emby server run for a couple of minutes now without scanning the lib and it stays on. So the crashes seem to occur while scanning only.

 

Edit3: Yup, started the scan and it crashed soon after..

 

Edit4: Okay, I just removed my music folder from the library and it scanned through my movies and tv shows without an error. Wut?

 

Edit5: Alright, now I've deleted and cleaned my library and activated the option to save metadata into media folders. This time the server just stops working, no exceptions no errors, it just stops... See the server-63595556181.txt log, it just stops..

 

Edit6: I looked at the output of dmesg and look what I found:

[432083.125300] Task in /lxc/112 killed as a result of limit of /lxc/112
[432083.125303] memory: usage 524136kB, limit 524288kB, failcnt 228205
[432083.125303] memory+swap: usage 655348kB, limit 655360kB, failcnt 16747594
[432083.125304] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
[432083.125305] Memory cgroup stats for /lxc/112: cache:768KB rss:523388KB rss_huge:0KB mapped_file:112KB dirty:0KB writeback:0KB swap:131204KB inactive_anon:262124KB active_anon:261268KB inactive_file:148KB active_file:108KB unevictable:0KB
[432083.125311] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[432083.125486] [29452]     0 29452     3871        9      13       3       33             0 init
[432083.125490] [30292]     0 30292     9267       15      23       3       84             0 rpcbind
[432083.125492] [30437]     0 30437    64666       50      28       4       93             0 rsyslogd
[432083.125494] [30518]     0 30518     4753        0      14       3       50             0 atd
[432083.125496] [30550]   102 30550    10529        1      24       3       84             0 dbus-daemon
[432083.125499] [30575]     0 30575    13791        1      30       3      165         -1000 sshd
[432083.125501] [30582]     0 30582     6473        9      18       3       49             0 cron
[432083.125503] [30714]     0 30714     9038       19      22       3      124             0 master
[432083.125505] [30723]   100 30723     9554       18      21       3      117             0 pickup
[432083.125507] [30724]   100 30724     9566       21      24       3      116             0 qmgr
[432083.125509] [30781]     0 30781     3164        1      11       3       34             0 getty
[432083.125511] [30782]     0 30782     3164        2      11       3       34             0 getty
[432083.125514] [30805]     0 30805    20676        3      44       3      212             0 sshd
[432083.125516] [30812]  1000 30812    20676       44      42       3      189             0 sshd
[432083.125518] [30813]  1000 30813     5289        0      16       3      348             0 bash
[432083.125520] [30827]  1000 30827    11186        2      28       3       92             0 su
[432083.125523] [30912]     0 30912     5350      211      15       3      203             0 bash
[432083.125533] [27512]     0 27512    11186        2      27       4       91             0 su
[432083.125534] [27526]   103 27526   727904   127885     624       7    33314             0 mono-sgen
[432083.125536] [27970]     0 27970     1066        5       8       3       15             0 tail
[432083.125538] Memory cgroup out of memory: Kill process 27526 (mono-sgen) score 987 or sacrifice child
[432083.126124] Killed process 27526 (mono-sgen) total-vm:2911616kB, anon-rss:511540kB, file-rss:0kB

Seems like I haven't given the container enough ram and lxc seems to kill the process that eats the memory. Even though I gave the container 512MB RAM which is the minimum for Emby...

Attached Files


Edited by shawly, 06 April 2016 - 10:59 AM.


#4 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 07 April 2016 - 08:17 AM

Alright, I'll give up, Emby still crashes randomly when I scan the library while configuring things. It also crashes when I install a plugin and hit restart.

And since I don't get any support I can't do anything about it.



#5 gsnerf OFFLINE  

gsnerf

    Advanced Member

  • Members
  • 121 posts
  • Local time: 12:43 AM
  • LocationBerlin (Germany)

Posted 09 April 2016 - 04:29 AM

It is a bit harsh for a container system to kill processes inside the container because they eat "to much" RAM?

In any way, scanning the library will eat a lot of memory, I don't know if 512MB is enough for that. I'd at least double that and see if if helps.



#6 MrJonny OFFLINE  

MrJonny

    Advanced Member

  • Members
  • 63 posts
  • Local time: 12:43 AM

Posted 12 April 2016 - 03:27 PM

I got Emby in a container, how much ram does it have access too?

Memory cgroup out of memory: Kill process 27526 (mono-sgen) score 987 or sacrifice child

 

I allowed my container to have 2GB. out of my 32GB



#7 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 12 April 2016 - 03:30 PM

I obviously increased the RAM of my container, but like I already said Emby still crashes randomly with no kernel error, no exceptions in the log, it just crashes. So fuck it.



#8 hurricanehrndz OFFLINE  

hurricanehrndz

    Advanced Member

  • Developers
  • 1249 posts
  • Local time: 04:43 PM

Posted 13 April 2016 - 12:38 PM

I obviously increased the RAM of my container, but like I already said Emby still crashes randomly with no kernel error, no exceptions in the log, it just crashes. So fuck it.

Great attitude. If you are trying to do something for yourself you should expect issues. Emby does not crash when used in our developed container or even on standalone systems. So obviously it has something to do with how your developing your container. 



#9 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 13 April 2016 - 12:39 PM

k



#10 Cerothen OFFLINE  

Cerothen

    Advanced Member

  • Members
  • 213 posts
  • Local time: 07:43 PM

Posted 14 April 2016 - 12:34 AM

I have successfully been running emby in an openvz / lxc container for about 8 months with no issues. I started with a turnkey core package, added the repo for emby, update and install. There have been no other system changes in the core outside of regular emby configuration.

Edit: PS started on openvz and transitioned to lxc when updating from pve 3.4 to 4.1

Edited by Cerothen, 14 April 2016 - 12:36 AM.

  • hurricanehrndz likes this

#11 shawly OFFLINE  

shawly

    Newbie

  • Members
  • 9 posts
  • Local time: 01:43 AM

Posted 14 April 2016 - 03:24 AM

I have successfully been running emby in an openvz / lxc container for about 8 months with no issues. I started with a turnkey core package, added the repo for emby, update and install. There have been no other system changes in the core outside of regular emby configuration.

Edit: PS started on openvz and transitioned to lxc when updating from pve 3.4 to 4.1

 

Thanks for your reply, I'm also on pve 4.1, but I haven't tried the turnkey core package yet. So I'll give it a try!



#12 Cerothen OFFLINE  

Cerothen

    Advanced Member

  • Members
  • 213 posts
  • Local time: 07:43 PM

Posted 14 April 2016 - 06:55 AM

If your still having issues you could also double check permissions and what user the share is mounted on in the host.

Start with 0777 and you can change it later

Edited by Cerothen, 14 April 2016 - 06:56 AM.


#13 hurricanehrndz OFFLINE  

hurricanehrndz

    Advanced Member

  • Developers
  • 1249 posts
  • Local time: 04:43 PM

Posted 14 April 2016 - 06:20 PM

@Cerothen

 

Thanks for jumping in and giving your feedback.







Also tagged with one or more of these keywords: lxc

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users