Jump to content

4.4.3.0 upgrade release caused core dump and will not start


Recommended Posts

lolmcbride

Running on Linux Mint and I've done many upgrades without issue before. Was running 4.4.2.0 and upgraded to 4.4.3.0 but had core dump fault:


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: failed (Result: core-dump) since Tue 2020-06-02 18:57:04 BST; 2s ago Process: 4770 ExecStart=/opt/emby-server/bin/emby-server (code=dumped, signal=ABRT) Main PID: 4770 (code=dumped, signal=ABRT)


Jun 02 18:57:03 monster emby-server[4770]: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, Jun 02 18:57:03 monster emby-server[4770]: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, Jun 02 18:57:03 monster emby-server[4770]: at Emby.Server.Implementations.Logging.FileLogger..ctor(String path) Jun 02 18:57:03 monster emby-server[4770]: at Emby.Server.Implementations.Logging.SimpleLogManager.ReloadLogger(LogSeve Jun 02 18:57:03 monster emby-server[4770]: --- End of inner exception stack trace --- Jun 02 18:57:03 monster emby-server[4770]: at System.Threading.Tasks.Task.WaitAllCore(Task[] tasks, Int32 millisecondsT Jun 02 18:57:03 monster emby-server[4770]: at System.Threading.Tasks.Task.WaitAll(Task[] tasks) Jun 02 18:57:03 monster emby-server[4770]: at EmbyServer.Program.Main(String[] args) Jun 02 18:57:04 monster systemd[1]: emby-server.service: Main process exited, code=dumped, status=6/ABRT Jun 02 18:57:04 monster systemd[1]: emby-server.service: Failed with result 'core-dump'.


Tried downgrading to 4.4.2.0 but same issue, also tried removing and installing 4.4.2.0 with the same result. Anyone else have this issue?


Link to post
Share on other sites
lolmcbride

Thanks for your help.

Did the new upgrade create the emby user and change the service config file to that user?

I was running it before as my normal user but once I changed ownership of /var/log/emby and everything underneath it to emby:emby it all came back and is working.

Link to post
Share on other sites
Luke

Hi, the upgrade didn't do anything new, but if you edited the service files then it may have changed them back.

Link to post
Share on other sites
lolmcbride

No, I didn't change anything at all - the sequence of events was, waaaaaaaaay back when I fist installed Emby on this box I ran the service in my user name as the NFS shares to my NAS box were only accessible that way due to the permissions I'd done on FreeNAS and I've been running it like that ever since. I've never needed to redo the service config file since that time.

 

I've upgraded numerous times with zero issues (earliest I clearly remember is 4.1.x but this time it broke as soon as I upgraded. As it happens I've changed my NAS and NFS shares permissions (weeks ago so it isn't related to this issue) so changing to user emby wasn't a problem when I applied the fix in your earlier post as the permissions are more promiscuous.

Link to post
Share on other sites
lolmcbride
So, it's definitely the upgrade here is the terminal output going from 4.4.2 to 4.4.3:

Preparing to unpack emby-server-deb_4.4.3.0_amd64.deb ...

Removed /etc/systemd/system/multi-user.target.wants/emby-server.service.

Unpacking emby-server (4.4.3.0) over (4.4.2.0) ...

Setting up emby-server (4.4.3.0) ...

usermod: no changes

Created symlink /etc/systemd/system/multi-user.target.wants/emby-server.service → /usr/lib/systemd/system/emby-server.service.

Processing triggers for libc-bin (2.27-3ubuntu1) ...

Processing triggers for ureadahead (0.100.0-21) ...

 

As I stated previously, I was running emby with my normal user name but this upgrade changed the user that the service ran under to emby which caused my issues. 

Link to post
Share on other sites
Luke

Ok thanks for the feedback. We'll look into it.

Link to post
Share on other sites
  • 4 months later...
al92780

There is no emby directory under /var/log, i changed their ownership and group to emby.  attached is the output of sudo systemctl status emby-server.service

emby start fail

Link to post
Share on other sites
Q-Droid

It should be /var/lib/emby, unless RPi is different.

id emby
echo ~emby
ls -la ~emby

If the emby home directory doesn't exist then create it with emby:emby ownership.

 

Link to post
Share on other sites
al92780
On 6/4/2020 at 1:27 AM, lolmcbride said:

Thanks for your help.

Did the new upgrade create the emby user and change the service config file to that user?

I was running it before as my normal user but once I changed ownership of /var/log/emby and everything underneath it to emby:emby it all came back and is working.

The “emby” was not present in my rpi4. 

Link to post
Share on other sites
al92780
17 hours ago, Q-Droid said:

It should be /var/lib/emby, unless RPi is different.

id emby
echo ~emby
ls -la ~emby

If the emby home directory doesn't exist then create it with emby:emby ownership.

 

I did the following:

     mkdir /var/lib/emby

     sudo chown emby:emby /var/lib/emby

Solved problem.

Performed an rpi-upgrade prior.  

lighttpd.service failed to activate, did not try to correct

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...