[Ubuntu] "Exiting because another instance is already running" after reboot
Posted 04 September 2019 - 02:14 PM
Every time I reboot my server, Emby is down.
systemctl status emby-server gives me that:
● emby-server.service - Emby Server is a personal media server with apps on just about every device. Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; vendor preset: enabled) Active: inactive (dead) since Wed 2019-09-04 20:04:43 CEST; 7min ago Main PID: 1131 (code=exited, status=0/SUCCESS) Sep 04 20:04:38 nuc systemd: Started Emby Server is a personal media server with apps on just about every device.. Sep 04 20:04:43 nuc emby-server: Exiting because another instance is already running.
I don't believe I made any change to the systemd settings:
[Unit] Description=Emby Server is a personal media server with apps on just about every device. After=network.target [Service] EnvironmentFile=/etc/emby-server.conf WorkingDirectory=/opt/emby-server ExecStart=/opt/emby-server/bin/emby-server RestartForceExitStatus=3 User=emby [Install] WantedBy=multi-user.target
I don't have any issue with my other services.
Any idea how to fix this?
Edited by sephrat, 04 September 2019 - 02:14 PM.
Posted 04 September 2019 - 02:42 PM
Hi, was any emby server log generated?
No there was not. Last entry in the log is about shutting down:
2019-09-04 19:21:18.869 Info HttpServer: Stopping HttpListener... 2019-09-04 19:21:18.890 Info HttpServer: HttpListener stopped 2019-09-04 19:21:18.940 Info App: Disposing CoreAppHost 2019-09-04 19:21:18.941 Info App: Disposing LoopUtilEntryPoint 2019-09-04 19:21:18.941 Info App: Disposing SyncNotificationEntryPoint 2019-09-04 19:21:18.962 Info App: Disposing SyncManagerEntryPoint 2019-09-04 19:21:18.968 Info App: Disposing ConnectEntryPoint 2019-09-04 19:21:18.968 Info App: Disposing Notifications 2019-09-04 19:21:18.970 Info App: Disposing EncodingManagerEntryPoint 2019-09-04 19:21:18.970 Info App: Disposing MediaEncoderEntryPoint 2019-09-04 19:21:18.970 Info App: Disposing ActivityLogEntryPoint
After that in journalctl I can see this:
Sep 04 19:21:19 nuc systemd: Stopped Emby Server is a personal media server with apps on just about every device.. -- Reboot -- Sep 04 20:04:38 nuc systemd: Started Emby Server is a personal media server with apps on just about every device.. Sep 04 20:04:43 nuc emby-server: Exiting because another instance is already running.
(timestamp seem off but I truncated the log for independant reasons)
Posted 18 October 2019 - 09:42 AM
Starting from some point in time, Emby service doesn't start after a reboot.
I just did a test during the upgrade to 188.8.131.52. The reboot before the upgrade went well. I tried 2 reboots after the update and after none of them did Emby start automatically. A simple "systemctl start emby-server" boots it up, and after that we're back to normal: Emby starts upon the next reboot.
Posted 21 October 2019 - 10:06 AM
I haven't set up any dependencies based on Emby. My systemd service is pasted in my first post, and I don't believe any of my services is set to start after or before Emby.
This may be nothing but I noticed that there are 2 files for emby service, is that normal?
$ ls -l /usr/lib/systemd/system/emby* -rw-r--r-- 1 root root 316 Aug 22 2017 /usr/lib/systemd/system/emby-server.service -rw-r--r-- 1 root root 314 Aug 22 2017 /usr/lib/systemd/system/emby-server@.service
[Unit] Description=Emby Server is a personal media server with apps on just about every device. After=network.target [Service] EnvironmentFile=/etc/emby-server.conf WorkingDirectory=/opt/emby-server ExecStart=/opt/emby-server/bin/emby-server RestartForceExitStatus=3 User=%i [Install] WantedBy=multi-user.target
(the only difference with the other file is "User=%i" instead of "User=emby")
Could changing the startup order correct it? A delay for Emby?
I'm not an Ubuntu guru, how can you influence systemd by other means than "Wants"/"After"/"Before" instructions?
What's puzzling me is that it seems to start OK everytime I reboot, except right after an Emby update. This makes it hard to trackdown because I have to wait for an update to run another test.
Posted 21 October 2019 - 11:02 AM
I think your dir listing is valid, '@' file is a template.
Yes, those instructions would be a way to alter the startup if you had service dependencies in your config. I believe overrides are the "clean" way to do so in systemd.
Posted 28 January 2020 - 10:24 AM
After months of procrastinating this and manually starting the service every once in a while, I finally found the pattern to reproduce the issue every time.
Once I restart the server from the web interface, I will get this error upon next reboot.
Upgrading the server with dpkg does not trigger the issue.
Restarting the server with systemctl restart does not trigger the issue either.
Can anyone else reproduce or is it something to do with my setup ?
Could it be the restart from web UI messes something up with the mutex lock? I don't get how it could postpone the issue to the next reboot though...
Edit: Well, nevermind, seems the pattern I found is not consistent. Sometimes I don't get the issue when I restart from Web UI, sometimes I get the issue without restarting from Web UI.
Back to black magic in reboot logic.
Edited by sephrat, 28 January 2020 - 10:43 AM.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users