[SOLVED] 3.0.5816 unable to start emby-server (status126)

[eggithub]

Just upgraded emby-server to 3.0.5816. Couldn't start last stable emby-server either.

Status:
service emby-server status
● emby-server.service - Emby Media Server
Loaded: loaded (/lib/systemd/system/emby-server.service; disabled)
Active: failed (Result: exit-code) since Thu 2016-01-21 20:41:04 CET; 16min ago
Process: 3727 ExecStopPost=/usr/bin/emby-server clear (code=exited, status=0/SUCCESS)
Process: 3704 ExecStart=/usr/bin/emby-server start (code=exited, status=126)
Main PID: 3704 (code=exited, status=126)

Jan 21 21:06:18 su[3941]: Successful su for emby by root
Jan 21 21:06:18 su[3941]: + ??? root:emby
Jan 21 21:06:18 su[3941]: pam_unix(su:session): session opened for user emby by (uid=0)
Jan 21 21:06:18 systemd[1]: emby-server.service: main process exited, code=exited, status=126/n/a
Jan 21 21:06:18 systemd[1]: Unit emby-server.service entered failed state.

Log:
cat /var/log/emby-server.log
env: /usr/lib/emby-server/.w3m: Permission denied

Any ideas?

Cheers!

[eggithub]

Ok, think I've found it:

changed the /usr/bin/emby-server line:

MONO_EXEC_ENV="$MONO_ENV LD_LIBRARY_PATH=${MAGICK_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"

MONO_EXEC_ENV="$MONO_ENV LD_LIBRARY_PATH=${MAGICK_LIBRARY_PATH:+:}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"

Appears to be the same prob as in post:

http://emby.media/community/index.php?/topic/28617-issue-with-beta-3057816/?p=276658

[hurricanehrndz]

Issue has been resolved. It was on line 1. #/bin/sh to #/bin/bash -- it was missed because of trying to keep all the wrapper scripts align across distros.

[hurricanehrndz]

PS the right project files are here:
https://github.com/MediaBrowser/Emby.Build/tree/master/builders/emby-server/debfiles

[hurricanehrndz]

MediaBrowser/Emby.Build#42

[eggithub]

I think you still need to update your PATH settings in the script, like I stated above... I reverted and only changed the first line but that brought me back to the original prob. status126...

line 56 you need to add the :+: to you know where...

[hurricanehrndz]

One sec, I will write a test script for you and will like the results back.

[eggithub]

Sure, but I'm merely noob+ on these kinda things ;)

[hurricanehrndz]

can you please run this

#!/bin/bash
MAGICK_LIBRARY_PATH=$(find /usr/lib/emby-server/ -maxdepth 1 -mindepth 1 -type d| grep -v bin)
MONO_EXEC_ENV="$MONO_ENV LD_LIBRARY_PATH=${MAGICK_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"

echo "$MONO_EXEC_ENV"

[eggithub]

I get this back from shell:

LD_LIBRARY_PATH=/usr/lib/emby-server/.config
/usr/lib/emby-server/.w3m

[hurricanehrndz]

Okay, I see the issue, for some reason in your configuration you have folders in /usr/lib/emby-server which are not suppose to be there.

[eggithub]

started using emby about 2 months ago and started of with this page for debian 8

https://software.opensuse.org/download.html?project=home%3Aemby&package=emby-server

didnt edit anything in the project up to tonight.

Strange thing was I couldnt connect to emby server all of a sudden this afternoom. So I ugraded to 5816 version, although the prob seemed to appear in
emby-server_3.0.5786_all as well.

Is there any info I can help you out with?

[hurricanehrndz]

Yes, its a recent change we made in order to ensure that our version of imgaemagick doesn't conflict with the one distributed by default with each distro. Some users complained of not being able to run gimp and other apps that depended on imagemagick.

[eggithub]

I can remember having issues with those libraries on first install. Had to start from scratch a couple of time cause of dependancy issues.

[hurricanehrndz]

Exactly so we made our version of imagemagick that was a shared library not system installed one. Because of differing arch we needed to be able to find lib directories in '/usr/lib/emby-server' hence we added those two lines that are giving you trouble. Unfortunately during our testing we never had an example where there were other folders other than lib, lib64 and bin.

[hurricanehrndz]

Please test this:

#!/bin/bash
MAGICK_LIBRARY_PATH=$(find /usr/lib/emby-server/ -maxdepth 1 -mindepth 1 -type d| grep -v bin | grep -v -e "/usr/lib/emby-server/\.")
MONO_EXEC_ENV="$MONO_ENV LD_LIBRARY_PATH=${MAGICK_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"

echo "$MONO_EXEC_ENV"

[eggithub]

shell gives me:

LD_LIBRARY_PATH=

[hurricanehrndz]

Okay. PS I don't think you have libembymagick installed, which is fine, but it does increase performance over the WAN.
Please give me the output of:
ls /usr/lib/emby-server
dpkg -l | grep emby

[eggithub]

~$ ls /usr/lib/emby-server
bin restart.sh
~$ dpkg -l | grep emby
ii emby-server 3.0.5816 all Emby Server is a home media server.

[hurricanehrndz]

Yup you don't have our embymagick packages, again this is another scenario which we didn't think about I guess. Any reason why you don't have them?

[hurricanehrndz]

#!/bin/bash
MAGICK_LIBRARY_PATH=$(find /usr/lib/emby-server/ -maxdepth 1 -mindepth 1 -type d| grep -v bin | grep -v -e "/usr/lib/emby-server/\.")
MONO_EXEC_ENV="$MONO_ENV ${LD_LIBRARY_PATH:+"LD_LIBRARY_PATH="}${MAGICK_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"

echo "$MONO_EXEC_ENV"

This should give you nothing which is probably what you want.

[eggithub]

As I said, I installed to test emby, got dependancy problems so I fooled around a little trying to solve this not really knowing what I was doing. Finally got it to work and didn't bather abou that specific package from then on

[eggithub]

yep, shell output is empty...

[hurricanehrndz]

That package libembymagick is brand new. You don't need to have and if you feel comfortable without it then that's cool. I though I would just let you know that images being transmitted over the wan will be slow because you have no access to imagemagick.

[hurricanehrndz]

PS libembymagick does not conflict or interfere with imagemagick

[hurricanehrndz]

Okay thank you. I will be updating the script with the fixes now.

[eggithub]

what does it do? compress stuff or something? and why didnt you use the system package?

[eggithub]

Ok np and good luck.

[hurricanehrndz]

lol, I have answer this question 100 times but okay. One yes it does compress.
Two. imagemagick across all the distributions are all compiled differently. Debian and Ubuntu do not seem to include webp which is the default compression we use. Additionally, imagemagick in the distros is compiled to do threading on each image, which is good when processing large image files. But in our case we are trying to process reasonably sized files but lots of them so its better if we thread the process ourselves. Also, we use a better compression algorithm q8 rather than q16 for better performance.

[hurricanehrndz]

Without the libembymagick there is no compression on the images.

[hurricanehrndz]

There should be a new build in 1 hour addressing your issue.

[eggithub]

ok, I understand now... You might want to make a template from that previous piece of text for future questions ;-)

good luck with the project and keep up the god work!

Cheers

Ok, i'll try it tomorrow...

[hurricanehrndz]

Ha ha. Good call, maybe I'll add it to the wiki