Jump to content

Emby crashes upon start


sse450
Go to solution Solved by Happy2Play,

Recommended Posts

I updated Centos to  7.3.1611. Now, emby-server (both release and beta) crashes immediately upon start.

 

emby-server-3.1.2

mono-core-4.6.2

 

This is what I get on "systemctl status emby-server":

 

[root@@Media ~]# systemctl status emby-server
● emby-server.service - Emby Media Server
   Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2016-12-29 21:06:51 +03; 2s ago
  Process: 5513 ExecStopPost=/usr/lib/emby-server/emby-server.sh clear (code=exited, status=0/SUCCESS)
  Process: 5466 ExecStart=/usr/lib/emby-server/emby-server.sh start (code=exited, status=3)
 Main PID: 5466 (code=exited, status=3)
 
Dec 29 21:06:43 media.server.hme systemd[1]: Started Emby Media Server.
Dec 29 21:06:43 media.server.hme systemd[1]: Starting Emby Media Server...
Dec 29 21:06:43 media.server.hme su[5466]: (to emby) root on none
Dec 29 21:06:51 media.server.hme systemd[1]: emby-server.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
Dec 29 21:06:51 media.server.hme systemd[1]: Unit emby-server.service entered failed state.
Dec 29 21:06:51 media.server.hme systemd[1]: emby-server.service failed.
Link to comment
Share on other sites

ptrawles

I was getting the same message this evening and it turned out to be an NFS issue. My media is on an NFS export that failed to mount at boot time which caused Emby to puke - generating this exact message in /var/log/messages.

 

In /var/lib/emby-server/logs there was an unhandled* file created each time I tried to start the service that was much less than helpful. Looking through the server log in same directory it was pretty obvious that mono was throwing a fit about each of the library directories that were not mounted. An update to Freenas needed a configuration tickle to make the NFS export return to happiness.

 

While t would be nice if Emby logged a cleaner error for a missing library location for folks that are less experienced with *NIX, a little digging should make the issue clear.

 

Link to comment
Share on other sites

I was getting the same message this evening and it turned out to be an NFS issue. My media is on an NFS export that failed to mount at boot time which caused Emby to puke - generating this exact message in /var/log/messages.

 

In /var/lib/emby-server/logs there was an unhandled* file created each time I tried to start the service that was much less than helpful. Looking through the server log in same directory it was pretty obvious that mono was throwing a fit about each of the library directories that were not mounted. An update to Freenas needed a configuration tickle to make the NFS export return to happiness.

 

While t would be nice if Emby logged a cleaner error for a missing library location for folks that are less experienced with *NIX, a little digging should make the issue clear.

 

Hi @@ptrawles, thanks for the info. if you can please supply your logs from earlier i can make sure those log messages are accompanied with additional information. thanks !

Link to comment
Share on other sites

I think I have exactly the same problem as @@ptrawles. My data is also on NAS with nfs exports.

 

Logs:

 

server.txt: http://pastebin.com/VuWDcTms

 

unhandled.txt: http://pastebin.com/dALdqdpk

 

This emby server was working nicely with the same NAS before. I updated CentOS and emby-server. Now I get this.

 

Hi @@sse450, do you have folders in library setup that no longer exist?

2016-12-30 11:07:10.4072 Error LibraryMonitor: Error watching path: /mnt/NAS/multimedia/3dmovie
    *** Error Report ***
    Version: 3.1.2.0
    Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
    Operating system: Unix 3.10.0.514
    64-Bit OS: True
    64-Bit Process: True
    Mono: 4.6.2 (Stable 4.6.2.7/08fd525 Tue Nov 29 22:31:42 UTC 2016)
    Processor count: 6
    Program data path: /var/lib/emby-server
    Application directory: /usr/lib/emby-server/bin
    System.ArgumentException: Directory does not exist

Normally we should be able to recover from this but the mono realtime monitor is throwing an error that we're not able to catch, so that is why the server is crashing.

 

If you can't startup at all, then what you can do is go here:

/var/lib/emby-server/root/default

And manually delete the library folders that are no longer valid.

Link to comment
Share on other sites

I identified the problem. NAS is too slow during starting compared to emby server. So, emby cannot find any nfs shares ready for its use. Hence it crashes. I think emby should start even if it cannot find any library share.

 

Anyway, I installed autofs to make sure that shares are ready when emby needs them. Then I manually deleted all the folders in 

/var/lib/emby-server/root/default 

and wanted to change paths of the library folders. Emby still crashes with the following error:

2016-12-31 14:50:03.9100 Error Main: UnhandledException
        *** Error Report ***
        Version: 3.1.266.0
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 3.10.0.514
        64-Bit OS: True
        64-Bit Process: True
        Mono: 4.6.2 (Stable 4.6.2.7/08fd525 Tue Nov 29 22:31:42 UTC 2016)
        Processor count: 6
        Program data path: /var/lib/emby-server
        Application directory: /usr/lib/emby-server/bin
        System.NullReferenceException: Object reference not set to an instance of an object
          at System.IO.FileSystemWatcher.Stop () [0x00000] in <bd46d4d4f7964dfa9beea098499ab597>:0
          at System.IO.FileSystemWatcher.Finalize () [0x00007] in <bd46d4d4f7964dfa9beea098499ab597>:0
        System.NullReferenceException
          at System.IO.FileSystemWatcher.Stop () [0x00000] in <bd46d4d4f7964dfa9beea098499ab597>:0
          at System.IO.FileSystemWatcher.Finalize () [0x00007] in <bd46d4d4f7964dfa9beea098499ab597>:0

2016-12-31 14:50:03.9126 Info HttpClient: Checking for cache file /var/lib/emby-server/cache/httpclient/f70ca6622474da8168a3b6c06f651a16
2016-12-31 14:50:03.9249 Info TaskManager: Check for application updates Completed after 0 minute(s) and 0 seconds
2016-12-31 14:50:03.9249 Info ServerManager: Sending web socket message ScheduledTaskEnded
2016-12-31 14:50:03.9249 Info TaskManager: ExecuteQueuedTasks

I have no idea about this new error.

Link to comment
Share on other sites

that is coming from the mono runtime and it appears we're unable to catch and handle it. what you'll need to do is disable the realtime monitor for each library. are you able to get into the server at all so that you can do that?

Link to comment
Share on other sites

that is coming from the mono runtime and it appears we're unable to catch and handle it. what you'll need to do is disable the realtime monitor for each library. are you able to get into the server at all so that you can do that?

As I cannot start emby, it is not possible to disable it within dashboard. Is there a way to access that parameter in some emby config file?

Link to comment
Share on other sites

  • Solution
Happy2Play

There is an options.xml in (don't know exact path for this os) \Emby-Server\root\default\(your library name).  There is a folder for each library.

  <EnableRealtimeMonitor>true</EnableRealtimeMonitor>
  • Like 1
Link to comment
Share on other sites

mastrmind11

I identified the problem. NAS is too slow during starting compared to emby server. So, emby cannot find any nfs shares ready for its use. Hence it crashes. I think emby should start even if it cannot find any library share.

You don't want that either.  I've had Emby start up during an outage which left my NAS down (twice now), and when Emby checks for library updates, it assumes you've deleted your libraries and subsequently removes your all your media from Emby.  Depending on the size of your library, having to rescan from scratch can be a pita, especially if you don't realize what's happened until prime usage times and it's too late.

Edited by mastrmind11
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...