[Ubuntu] "Exiting because another instance is already running" after reboot

[sephrat 16]

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[1]: Started Emby Server is a personal media server with apps on just about every device..
Sep 04 20:04:43 nuc emby-server[1131]: Exiting because another instance is already running.

A simple "systemctl start emby-server" solves the issue but I have do that every time I reboot.

 

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 September 4, 2019 by sephrat

[Luke 37009]

Hi, was any emby server log generated?

[sephrat 16]

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[1]: Stopped Emby Server is a personal media server with apps on just about every device..
-- Reboot --
Sep 04 20:04:38 nuc systemd[1]: Started Emby Server is a personal media server with apps on just about every device..
Sep 04 20:04:43 nuc emby-server[1131]: Exiting because another instance is already running.

(timestamp seem off but I truncated the log for independant reasons)

[alucryd 214]

The emby-server unit should be enabled upon installation, but we've seen people who somehow masked the unit, so enabling can't work. Can you try enabling it (systemctl enable) and post the log?

[sephrat 16]

I'm pretty sure I already tried that when I troubleshot a few weeks ago but it seems to work!

Maybe it gets reset upon upgrade? I'll keep an eye on that.

Thanks!

[Luke 37009]

@@sephrat how did this go?

[sephrat 16]

So far so good. Since I enabled the service, Emby has always been up after a reboot. No idea what happened in the first place.

[Luke 37009]

Thanks for the feedback.

[sephrat 16]

Well I still don't understand the pattern but it keeps happening every now and then. I know for sure it happened twice since the last update but not after every reboot. I just enable the service again and pray for it to last.

[Luke 37009]

What exactly happens?

[sephrat 16]

Starting from some point in time, Emby service doesn't start after a reboot.

I just did a test during the upgrade to 4.3.0.15. 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. 

[Luke 37009]

When you reboot, how are you doing that? Is Emby server running when you reboot, or do you stop it first?

[sephrat 16]

I reboot with "sudo reboot". Yes Emby is running when I reboot, just like all my other services. Emby is the only one I have issue with.

[Q-Droid 634]

Are there internal or external dependencies not ready yet for Emby to start cleanly? Could changing the startup order correct it? A delay for Emby?

[sephrat 16]

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

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.

[Q-Droid 634]

I meant dependencies along the lines of external storage or devices not yet ready when Emby is started.

 

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.

[Luke 37009]

The message that you get about instance already running is the mutex lock we use on the machine to make sure only a single instance of the server can run at a time.

[sephrat 16]

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 January 28, 2020 by sephrat

[Luke 37009]

We'll try to reproduce this. Thanks for reporting.