Emby crashing - Fedora 25

[AciDCooL 7]

Heya Just wanted to let you know that Emby crashes allot on Fedora 25. And since the systemctl script does not auto start emby again it is getting pretty annoying. The only thing I can see that is consistent in the logs is the following sentence when emby has crashed:

 

2017-07-09 17:17:08.4019 Info TaskManager: ExecuteQueuedTasks

 

is there anyway I can create a crash dump or should I send a log file somewhere?

 

 

Edit:

Systemctl log:

Jul 09 17:17:57 acidcool.nl emby-server.sh[6146]: Session terminated, killing shell... ...killed.

 

and attached the log from emby from the same time.

Log.7z

Edited July 10, 2017 by AciDCooL

[Luke 42078]

Can you please attach the information requested in how to report a problem:

 

https://emby.media/community/index.php?/topic/790-how-to-report-a-problem/

 

Thanks.

[AciDCooL 7]

Sry you can close this case. dnf-automatic seemed to autoupdate emby, after the update emby closes but never starts up again. I added emby to the exclusion list so it doesn't autoupdate for now.

[Luke 42078]

How does that solve your crashing problem?

[Luke 42078]

I think your issue is more likely that you are using software called Ombi, and it is hammering your Emby Server with network requests. Try not using Ombi and seeing if the issue goes away.

[dcrdev 255]

This brings up an interesting point though - the Emby service is stopped when an upgrade is performed, but is never started up again.

 

@@Luke - Your spec file needs to incorporate a "systemctl start emby-server" within your %post section. Most likely in this block:

	DISTRIBUTOR=$(lsb_release -i | cut -f 2)
	RELEASE=$(lsb_release -r | cut -f 2 | cut -d . -f 1)
	if [ "$DISTRIBUTOR" == "Fedora" ]; then
		systemctl daemon-reload > /dev/null
	elif [ "$DISTRIBUTOR" == "CentOS" ]; then
		if [ "$RELEASE" == "6" ]; then
			chkconfig --add emby-server > /dev/null
		elif [ "$RELEASE" == "7" ]; then
			systemctl daemon-reload > /dev/null
		fi
	fi

Like this:

	DISTRIBUTOR=$(lsb_release -i | cut -f 2)
	RELEASE=$(lsb_release -r | cut -f 2 | cut -d . -f 1)
	if [ "$DISTRIBUTOR" == "Fedora" ]; then
		systemctl daemon-reload > /dev/null && \
		systemctl start emby-server > /dev/null
	elif [ "$DISTRIBUTOR" == "CentOS" ]; then
		if [ "$RELEASE" == "6" ]; then
			chkconfig --add emby-server > /dev/null && \
			service emby-server start > /dev/null
		elif [ "$RELEASE" == "7" ]; then
			systemctl daemon-reload > /dev/null && \
			systemctl start emby-server > /dev/null
		fi
	fi

Edited July 11, 2017 by dcrdev

[AciDCooL 7]

How does that solve your crashing problem?

 

I never crashed it just exited, which is why systemctl does not auto restart cause according the to system the program is exited correctly.

[Luke 42078]

I never crashed it just exited, which is why systemctl does not auto restart cause according the to system the program is exited correctly.

 

Ok, Try not using Ombi and seeing if the issue goes away. Thanks.

[mastrmind11 722]

Sry you can close this case. dnf-automatic seemed to autoupdate emby, after the update emby closes but never starts up again. I added emby to the exclusion list so it doesn't autoupdate for now.

Install Monit and set it up to auto restart emby if it goes down unexpectedly.  Works like a charm and bypasses the users texting/calling that shit's not working.

[AciDCooL 7]

I setup monit and works like a charm, apparently it autoupdated yesterday, and as usual it stopped working. Here the log for anyone interested.

 

[CEST Jul 12 00:11:12] info     : Starting Monit HTTP server at [*]:2815

[CEST Jul 12 00:11:12] info     : Monit HTTP server started

[CEST Jul 12 00:11:12] info     : 'xxxxl' Monit reloaded

[CEST Jul 19 15:54:00] info     : Starting Monit 5.14 daemon with http interface at [*]:2815

[CEST Jul 19 15:54:01] info     : Starting Monit HTTP server at [*]:2815

[CEST Jul 19 15:54:01] info     : Monit HTTP server started

[CEST Jul 19 15:54:01] info     : 'xxx' Monit 5.14 started

[CEST Jul 19 15:54:01] error    : 'emby-server' process is not running

[CEST Jul 19 15:54:01] info     : 'emby-server' trying to restart

[CEST Jul 19 15:54:01] info     : 'emby-server' start: /usr/bin/systemctl

[CEST Jul 19 15:55:03] info     : 'emby-server' process is running with pid 1536

[CEST Jul 19 20:14:58] info     : Shutting down Monit HTTP server

[CEST Jul 19 20:14:59] info     : Monit HTTP server stopped

[CEST Jul 19 20:14:59] info     : Monit daemon with pid [1458] stopped

[CEST Jul 19 20:14:59] info     : 'xxxxx' Monit 5.14 stopped

[CEST Jul 19 20:16:15] info     : Starting Monit 5.14 daemon with http interface at [*]:2815

[CEST Jul 19 20:16:16] info     : Starting Monit HTTP server at [*]:2815

[CEST Jul 19 20:16:16] info     : Monit HTTP server started

[CEST Jul 19 20:16:16] info     : 'xxx' Monit 5.14 started

[CEST Jul 19 20:16:16] error    : 'emby-server' process is not running

[CEST Jul 19 20:16:16] info     : 'emby-server' trying to restart

[CEST Jul 19 20:16:16] info     : 'emby-server' start: /usr/bin/systemctl

[CEST Jul 19 20:17:19] info     : 'emby-server' process is running with pid 1631

[CEST Jul 24 21:37:32] error    : 'emby-server' failed protocol test [DEFAULT] at [localhost]:8096 [TCP/IP] -- Connection refused

[CEST Jul 24 21:37:32] info     : 'emby-server' trying to restart

[CEST Jul 24 21:37:32] info     : 'emby-server' stop: /usr/bin/systemctl

[CEST Jul 24 21:38:34] info     : 'emby-server' connection succeeded to [localhost]:8096 [TCP/IP]

 

Although this feels like a workaround, for me this works.

Edited July 25, 2017 by AciDCooL

[Luke 42078]

What stopped working?

[AciDCooL 7]

Wel to be specific the proces stops then updates, either through a dnf update or even the autoupdate feature in the core program itself; And then never starts up again. Like explained bij dcrdev, there is no startup procedure in the spec file.

So now I am using monit to monitor the proces, to start it up again after an update or crash, or even a manual fuck up. (But to be clear, there has not been a crash so far, just my misinterpretation of the dnf autoupdate proces since emby never automatically starts)

[dcrdev 255]

Wel to be specific the proces stops then updates, either through a dnf update or even the autoupdate feature in the core program itself; And then never starts up again. Like explained bij dcrdev, there is no startup procedure in the spec file.

So now I am using monit to monitor the proces, to start it up again after an update or crash, or even a manual fuck up. (But to be clear, there has not been a crash so far, just my misinterpretation of the dnf autoupdate proces since emby never automatically starts)

 

Yes - you shouldn't need any external monitoring programs be responsible for starting up services, that is what systemd is for.

 

The problem here as I mentioned before (not that anyone ever listens) is that the emby service is being explicitly stopped as part of the upgrade process and is therefore not being restarted by systemd, or any other monitoring tool simply because it's not in a failed state i.e. it's exiting cleanly.

 

In your spec file - I believe you are making the assumption that if a unit is enabled and you call "daemon-reload" that will start back up any services, it won't that's not how systemd behaves.

 

I do a fair bit of packaging in Fedora and generally the convention is that packages don't autostart or shutdown - that is the responsibility of the user to do. However I get why you are explicitly stopping the service on %postun and I think the only logical thing to do would be to bring it back up in %post.

 

Also furthermore SUSE, Fedora and RHEL all have a systemd-rpm macros packages which you should be utilising and making use of %systemd_post, %systemd_preun and %systemd_postun will take a lot of the hassle out of what you're doing here.

 

Whilst I'm here - also Fedora and RHEL both use selinux - Emby simply won't start up unless you disable selinux; it's the simplest change to the service file in the world to get it going and yet after 2 years it still has not been made! You have to create another service file and put it in /etc/systemd/system so that it takes precedence over the packaged version of the file.

Edited July 26, 2017 by dcrdev