Emby doesn't start after upgrade to 3.4.0.0

[Luke 40137]

Unfortunately I can't answer that as it is specific to your environment. I will let you know when we have a beta build  up with the change. Thanks.

[fbrassin 46]

Tnk you so much

[jjnova 0]

I have the same issue. I think it's because emby is now installing to systemd but... we aren't using systemd. I can also manually launch the server using the aforementioned method.

[Luke 40137]

I think it's because emby is now installing to systemd but... we aren't using systemd.

 

Yes that might explain it, so you might have to start manually then.

[jjnova 0]

To clarify, during install there is this portion.

Created symlink /etc/systemd/system/multi-user.target.wants/emby-server.service → /usr/lib/systemd/system/emby-server.service.
Failed to start emby-server.service: Unknown unit: emby-server.service

I think this might be the source of the issue. Anyone using an init that isn't systemd will run into similar issues. If you don't want to keep a terminal open the entire time you want access to emby, you will also have to launch it as a background service.
 

Hopefully this will be addressed and systemd doesn't remain a requirement for emby.

 

In the meantime, it should be possible to launch emby with cron at launch.

sudo crontab -e

Select the editor you want to use (I like nano) and add the following to the end of the file.

@[member="reboot"] /opt/emby-server/bin/emby-server

Save changes and restart. It should theoretically work.  It's not ideal, it's not perfect, and it's not what anyone would expect to do after an upgrade, but it might get your media working again.

 

I will perform the steps and test.

[jjnova 0]

UPDATE:

 

The above steps (post #30) I laid out worked in my situation, and I am fairly certain it will work for most anybody else.

 

EDIT: For clarification purposes, the issue would also happen with the new installer, even after purging the old packages.

 

The following are tag words to help others find this thread when using a search engine to find solutions.

 

emby without systemd emby-server start systemctl emby-server.service

Edited May 6, 2018 by jjnova

[Luke 40137]

Thanks for the feedback.

[Luke 40137]

Tnk you so much

 

@@fbrassin the beta is up on the website, thanks.

[fbrassin 46]

Now it has started, using /opt/emby-server/bin/emby-server and manually creating /etc/emby-server-config pointing to /var/lib/emby-server and using latest beta.

 

Now i have to set autostart in crontab.

 

Just a question, which command should a i use to stop emby?

Edited May 7, 2018 by fbrassin

[Luke 40137]

I would shut it down using the web interface.

[fbrassin 46]

I have to pu it in a script.

 

Here is what i use:

killall -9 /opt/emby-server/system/EmbyServer

[Luke 40137]

If you abruptly kill the process that could lead to a corrupted database.

[alucryd 240]

While not life-threatening, running emby as root is not exactly a good idea, there's a reason we go through the trouble of creating a dedicated unpriviledged user. Also, regarding systemd, it's only used if systemctl is installed, not sure why you wouldn't want to use it if you have it installed. Please uninstall it if you don't use it as your init system, then emby will revert to using the ancient service command.

if [ -x "$(which systemctl)" ]; then
systemctl daemon-reload
systemctl enable emby-server || true
systemctl start emby-server || true
else
service emby-server start
fi

Edited May 7, 2018 by alucryd

[jjnova 0]

 

Please uninstall it if you don't use it as your init system, then emby will revert to using the ancient service command.

 

 

Wouldn't it make more sense to check and see if systemd is being used, as opposed to checking if it's installed?

[fbrassin 46]

If you abruptly kill the process that could lead to a corrupted database.

How could i stop emby in terminal without killing it?

[alucryd 240]

@@jjnova Sure, but there's no failproof way to determine which init is being used, and systemd has been the default virtually everywhere for quite some time now, it's fair to think it's being used if installed. It's not so far-fetched to expect users to uninstall it if they don't use it either.

 

@@fbrassin Just lose the -9 to send a SIGTERM instead.

[jjnova 0]

@@jjnova Sure, but there's no failproof way to determine which init is being used, and systemd has been the default virtually everywhere for quite some time now, it's fair to think it's being used if installed. It's not so far-fetched to expect users to uninstall it if they don't use it either.

 

I understand the reasoning, but in situations like myself and the others in this thread, where we have systemd-shim installed so that software such as CUPS will work, it fails.

 

Since there are only two options for emby (systemd or legacy) then we can check for an echo, and if there is no response we know to use legacy. For example...

strings /sbin/init | grep -q "/lib/systemd" && echo SYSTEMD"

If there is no echo of "SYSTEMD", then we can know to continue with the legacy installation. This would work for those who have systemd-shim installed for compatibility reasons only. I am unaware of any situation where this would provide a false positive, but I'm just one guy on the internet.

[fbrassin 46]

 

@@fbrassin Just lose the -9 to send a SIGTERM instead.

 

So it should be lkike this?

 

killall -s SIGTERM  /opt/emby-server/system/EmbyServer

[mastrmind11 722]

So it should be lkike this?

 

killall -s SIGTERM  /opt/emby-server/system/EmbyServer

no, SIGTERM (15) is the default for kill/killall/pkill, so not specifying any args will kill the process gracefully.

[bradford 5]

Every time I try to upgrade to 3.4.x I run into a problem. I'm running this in a Debian LXD container (on Proxmox) and systemd is a little weird. Anyway, I purge the opensuse repo installed version and try to install the deb package, which fails because systemd is not installed. I install systemd, but because it's an unprivileged container, it acts weird and doesn't work, so I roll back my container to 3.3.x. This upgrade process needs a detailed how-to posted somewhere because it is not straightforward.

Edited June 26, 2018 by bradford

[mastrmind11 722]

Every time I try to upgrade to 3.4.x I run into a problem. I'm running this in a Debian LXD container (on Proxmox) and systemd is a little weird. Anyway, I purge the opensuse repo installed version and try to install the deb package, which fails because systemd is not installed. I install systemd, but because it's an unprivileged container, it acts weird and doesn't work, so I roll back my container to 3.3.x. This upgrade process needs a detailed how-to posted somewhere because it is not straightforward.

Try the docker, easy peasy.

[bradford 5]

That might be a solution for you, but it's not any easier for me since I'm not already using docker. The devs need to fully address this for all of us who relied on the repo, instead of avoiding the issue. It's undermining my confidence in the project tbh. Something this simple should be addressed immediately, not 'when we get around to it'.

[Luke 40137]

I apologize for this. We should have done better with the transition in going from the older packages to the newer packages.