4.7.5.0 won't start due to faulty install process

[ember1205 23]

My server runs as a virtual guest. The process I followed is:

- Shut down server
- Take snapshot
- Boot and update openSUSE using zypper
- Reboot, test
- Shut down server
- Take snapshot
- Boot and update Emby to 4.7.5.0 using the zypper command from the download page

The install throws an error stating that the package header isn't signed, so I have to ignore it to proceed. Once installed, it will not start. The very first log entry indicates a permission error as:

2022-07-16T07:58:13.152494-04:00 embysrv emby-server[13950]: Error GlobalExceptionHandler: UnhandledException
2022-07-16T07:58:13.152604-04:00 embysrv emby-server[13950]: #011System.AggregateException: System.AggregateException: One or more errors occurred. (Access to the path '/var/lib/emby/logs/embyserver-1.txt' is denied.)
2022-07-16T07:58:13.152647-04:00 embysrv emby-server[13950]: #011 ---> System.UnauthorizedAccessException: Access to the path '/var/lib/emby/logs/embyserver-1.txt' is denied.

I checked the permissions to that directory and it shows the correct user and group (that I use, and have been using all along). So, I created the missing file, set the owner, and tried again. Same error comes back, but with the "next" file...

2022-07-16T08:01:40.179980-04:00 embysrv emby-server[14035]: Error GlobalExceptionHandler: UnhandledException
2022-07-16T08:01:40.180063-04:00 embysrv emby-server[14035]: #011System.AggregateException: System.AggregateException: One or more errors occurred. (Access to the path '/var/lib/emby/logs/embyserver-2.txt' is denied.)
2022-07-16T08:01:40.180322-04:00 embysrv emby-server[14035]: #011 ---> System.UnauthorizedAccessException: Access to the path '/var/lib/emby/logs/embyserver-2.txt' is denied.

The installation indicated that usermod made no changes.

 

What I ultimately found is that the systemd start file was replaced with a 'stock' one even though I had modified mine to allow Emby to run as a different user. This replacement should have some failsafe checks built into the installation process to determine when there may be an issue with replacing it. At the very least, the previous version should be renamed to preserve it in the event that something like this occurs. The fix was to edit /usr/lib/systemd/system/emby-server.service, set the username back to the one I require, and start the server.

 

Additionally, it would be helpful to log the actual userid that the daemon is attempting to start as, ESPECIALLY when permission issues are detected at launch.

[Luke 37230]

Hi, thanks for the info. We'll have to look at possible approaches to this.

The problem with keeping your modified file is that the new version could have other required charges that the server needs.

So if anything, we need a way to handle both concerns.

[ember1205 23]

34 minutes ago, Luke said:

Hi, thanks for the info. We'll have to look at possible approaches to this.

The problem with keeping your modified file is that the new version could have other required charges that the server needs.

So if anything, we need a way to handle both concerns.

What about breaking something like this out into a config file of its own?

 

Or running a sed script or similar to collect settings in the current file and then carrying them forward into a replacement file?

 

Maybe a script that compares the in-place file (or some settings in it) to an expected standard or similar and stops the install with a warning / directions?

[Luke 37230]

Quote

What about breaking something like this out into a config file of its own?

Yea I think that's probably what would have to happen.

[ember1205 23]

On 7/16/2022 at 11:58 AM, Luke said:

Yea I think that's probably what would have to happen.

4.7.6.0 - I had edit the service start script again.

 

(I expect it's known, just adding info for anyone else that may come across this or be following)

[Q-Droid 670]

There is a proper way to make systemd configuration changes and overrides so they are not lost when software is updated. As @Luke posted there may be changes needed in the configuration for an update and it would be nearly impossible to parse all of the customizations made by someone. It's up to the system owner to be the one making their own config file if they want to deviate from the defaults. A service config file backup during the update would be a nice addition from the Emby side just in case people do modify the config directly.

 

 

[ember1205 23]

22 minutes ago, Q-Droid said:

There is a proper way to make systemd configuration changes and overrides so they are not lost when software is updated. As @Luke posted there may be changes needed in the configuration for an update and it would be nearly impossible to parse all of the customizations made by someone. It's up to the system owner to be the one making their own config file if they want to deviate from the defaults. A service config file backup during the update would be a nice addition from the Emby side just in case people do modify the config directly.

 

 

Appreciate the comment and link...

 

I agree with what was stated about parsing every conceivable config and such not being feasible, and I offered ideas of how to potentially work around that (notice of changed file, separating items out so there's a config file, etc.). 

 

While the "edit" option may work, it's seemingly not at all documented (for use with Emby server). And, without it being documented (and supported) by the Emby team, there's no way to know if it will be usable in any particular version or following an update. Additionally, it could also very easily fall off of their radar for testing purposes going forward to ensure that a future update doesn't break that functionality (without being able to provide notice to users). In other words, there are ways to address the issue but they pretty much all start with some sort of ability to provide direction on them (documentation) and subsequently support them by the Emby team.

[Q-Droid 670]

It's not an Emby issue. Yes, it would help to have this option documented for users/admins running Emby on Linux distros using systemd. And really only those who want to change service defaults. But this is core systemd functionality that applies to any applications that make use of it and not specific to Emby. I don't agree that the Emby devs should be responsible for anticipating and testing for user customizations. Same goes for conflicts created when using systemd overrides. 

 

[ember1205 23]

10 minutes ago, Q-Droid said:

It's not an Emby issue. Yes, it would help to have this option documented for users/admins running Emby on Linux distros using systemd. And really only those who want to change service defaults. But this is core systemd functionality that applies to any applications that make use of it and not specific to Emby. I don't agree that the Emby devs should be responsible for anticipating and testing for user customizations. Same goes for conflicts created when using systemd overrides. 

 

While it may not be an issue directly caused by Emby, it is an issue that needs to be thought about and understood in order to ensure that the product will work correctly once installed. Software is all about the customizations, and running as a different user is extremely common with all sorts of products. If it's as straight-forward as implied, it should be just as straight-forward to test it, document it, and track it as a testing requirement going forward for the Emby team.

[Luke 37230]

We'll put a review of this on the to do list. Thanks.

[alucryd 217]

@ember1205As @Q-Droidstated, `systemctl edit` is the standard way of editing systemd services and is very well documented all over the internet already. However it sounds like we already provide all you need to achieve what you want without editing any service. Indeed, we also ship another systemd service, right beside `emby-server.service`, named `emby-server@.service`. It is specifically designed to run emby as another user, and follows the same conventions as many other services that achieve the same thing. All you need to do is:

systemctl stop emby-server
systemctl mask emby-server
systemctl enable --now emby-server@<insert_user_here>

and you're off to the races. No subsequent update will disrupt your setup. You can also modify where emby stores its settings by editing `/etc/emby-server.conf` and setting `EMBY_DATA` to any path other than `/var/lib/emby`. Hope that helps.

[ember1205 23]

4 hours ago, alucryd said:

@ember1205As @Q-Droidstated, `systemctl edit` is the standard way of editing systemd services and is very well documented all over the internet already. However it sounds like we already provide all you need to achieve what you want without editing any service. Indeed, we also ship another systemd service, right beside `emby-server.service`, named `emby-server@.service`. It is specifically designed to run emby as another user, and follows the same conventions as many other services that achieve the same thing. All you need to do is:

systemctl stop emby-server
systemctl mask emby-server
systemctl enable --now emby-server@<insert_user_here>

and you're off to the races. No subsequent update will disrupt your setup. You can also modify where emby stores its settings by editing `/etc/emby-server.conf` and setting `EMBY_DATA` to any path other than `/var/lib/emby`. Hope that helps.

All good info, and appreciated. My point is that, unless/until it appears in actual Emby documentation, it isn't a supported process. And if it isn't supported, a change down the road could effectively disable its ability to work (albeit likely unintentionally) due to it NOT being on the list of items to test for before a new version is released.