Jump to content

v3.2.60 doesn't fully quit


vangeliis

Recommended Posts

Hi,

 

I'm on a MacBook Pro running 10.13.2 and after updating to 3.2.60 I noticed every time I quit EmbyServer an instance of the server is left running in the background (see attached screenshots) and every time I restart and quit yet another instance is left running in the background. When I force quit the "lingering" instances within the Activity Monitor.app I get the following error message:

 
Info Dlna: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 127.0.0.1
Error Dlna: Error registering endpoint
*** Error Report ***
Version: 3.2.60.0
Command line: /Applications/EmbyServer.app/Contents/MacOS/EmbyServer.dll
Operating system: Unix 17.3.0.0
64-Bit OS: True
64-Bit Process: True
User Interactive: True
Processor count: 4
Program data path: /Users/vangelis/.config/emby-server
Application directory: /Applications/EmbyServer.app/Contents/MacOS
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Rssdp.SsdpDevicePublisher'.
  at Rssdp.Infrastructure.DisposableManagedObjectBase.ThrowIfDisposed()
  at Rssdp.Infrastructure.SsdpDevicePublisherBase.AddDevice(SsdpRootDevice device)
  at Emby.Dlna.Main.DlnaEntryPoint.<RegisterServerEndpoints>d__33.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
  at Emby.Dlna.Main.DlnaEntryPoint.<StartDlnaServer>d__32.MoveNext()
System.ObjectDisposedException
  at Rssdp.Infrastructure.DisposableManagedObjectBase.ThrowIfDisposed()
  at Rssdp.Infrastructure.SsdpDevicePublisherBase.AddDevice(SsdpRootDevice device)
  at Emby.Dlna.Main.DlnaEntryPoint.<RegisterServerEndpoints>d__33.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

 

  at Emby.Dlna.Main.DlnaEntryPoint.<StartDlnaServer>d__32.MoveNext()
 
Has anybody observed the same thing?
 
Thanks,
Vangeliis
 
Link to comment
Share on other sites

  • 4 weeks later...

the same here; on mac mini 2012, macOS Sierra, Exit from the menu icon does nothing, neither is "Configure",  and the server is not even local reachable!

How can I quit the server without having to restart the computer?

Edited by Everbrave
Link to comment
Share on other sites

the same here; on mac mini 2012, macOS Sierra, Exit from the menu icon does nothing and the server is not even local reachable!

How can I quit the server without having to restart the computer?

 

Can you try shutting down from the web interface and see how that compares? thanks.

Link to comment
Share on other sites

Can you try shutting down from the web interface and see how that compares? thanks.

 

 

I cannot reach the web interface, "Safari cannot open this page"!

Link to comment
Share on other sites

I Quit from the Activity Monitor but as I tried to remove the Server app, the finder told me it is still open; so I had to restart!

There is something really going wrong!

Link to comment
Share on other sites

the same here; on mac mini 2012, macOS Sierra, Exit from the menu icon does nothing, neither is "Configure",  and the server is not even local reachable!

How can I quit the server without having to restart the computer?

 

 

Hi,

 

Open a terminal window and run the following command (assuming you have copied EmbyServer.app into your Applications folder) :

/Applications/EmbyServer.app/Contents/MacOS/EmbyServer 

 

Leave the terminal window open. To quit Emby go to the open terminal window and hit ctrl-c. Don't be tempted to quit Emby from the menu bar icon as this does not work correctly at the moment.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

It's not a serious problem but I notice the Emby app doesn't appear to exit correctly, i.e.

  1. Launch Emby app
  2. Icon appears in menubar
  3. Exit Emby app using menubar icon
  4. Icon disappears but Emby process is still visible in Activity Monitor
  5. Launch Emby app
  6. Icon appears in menubar
  7. Now two Emby processes are visible in Activity Monitor

This also happens when Emby is restarted from the web interface - each restart creates an additional Emby process. I discovered this because I had the Server Restart plugin configured to run nightly and after 8 days there were 8 Emby processes.

 

Activity monitor after multiple restarts:

5a6f8660f36f4_a.png

 

Note: Running the latest version (3.2.70.0)

 

NOTE: Merged from duplicate thread

Edited by Anon28109
Link to comment
Share on other sites

Quit in Activity Monitor exits the Emby process correctly. Force Quit is not necessary nor is a system restart (as of v3.2.70.0)

 

Can you try shutting down from the web interface and see how that compares? thanks.

 

Behavior is the same whether Emby is shutdown from the menubar, from the web interface, or restart from the web interface (which results in an additional Emby process for every restart.)

Link to comment
Share on other sites

Hi @@Anon28109

 

I also get multiple lingering processes with v.3.2.70. Not sure if @@Luke can reproduce the problem on his test machine. Nothing can do at the moment other than "killing" embyserver from the Activity monitor.

 

V

Link to comment
Share on other sites

  • 4 weeks later...

I can reproduce. I'm still looking into it, thanks.

 

 

Hi @@Luke

Just to let you know v3.3 doesn't fix the problem with Emby processes still running in the background after quit. 

Link to comment
Share on other sites

  • 2 months later...

I apologize. I wasn't able to get to this in time and I didn't want it to hold up the release. It's on our list. Thanks.

Link to comment
Share on other sites

  • 3 weeks later...
ChrisJ60

I'm also having this issue (Emby 3.4.1, macOS 10.13.4). It is a big inconvenience since once this happens I have to kill the server process (for example kill -TERM pid) and then once I have done that I cannot start a new EmbyServer until I log out of the Mac and log back in (seems there is still some other 'resource' left lying around). Since this Mac is a 'server' which needs to be always logged in this is extremely disruptive.

 

Any chance of a fix soon please?

 

Thanks.

Link to comment
Share on other sites

vangeliis

Hi @@ChrisJ60

 

Can you try the suggestion in #9 for now? Should also work in a script  ;)  

Edited by vangeliis
Link to comment
Share on other sites

ChrisJ60

Hi @@ChrisJ60

 

Can you try the suggestion in #9 for now? Should also work in a script  ;)  

 

So here's the thing. This is quite different to running Emby in the usual way and it means I need to have a terminal session open all the time (ugh!) or I have to add extra stuff to run it in the background using 'nohup', save the pid, have another script to kill it etc. Maybe acceptable as a very short term workaround but this issue really needs to be fixed.

 

More worrying, when I try this it seems that Emby does not 'trap' SIGINT (Ctrl-C) and terminate gracefully but just dies. Having already had a bad experience where one of the Emby SQLLite databases got corrupted after a power outrage (looks like poor choice of database persistence options) it seems this approach risks database corruption every time the EmbyServer is stopped. probably not the best solution?

Link to comment
Share on other sites

vangeliis

You could try pkill -SIGINT -i EmbyServer

 

Probably it also needs pkill -SIGINT -i Electron

Edited by vangeliis
Link to comment
Share on other sites

ChrisJ60

That will certainly kill it. My concern, as I mentioned, is that as far as I can see Emby does not trap/handle this so it just dies with all the associated risks of corrupt databases etc. How does the shutdown work when initiated from the WebUI? What mechanism does that use? I'd much prefer a guaranteed clean way to shut it down to avoid any risk.

Link to comment
Share on other sites

vangeliis

The best thing to do right now is to keep frequent backups of the ~./config/data folder.

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...