Preparing to unpack .../plexmediaserver_1.15.0.659-9311f93fd_amd64.deb ...
Removed /etc/systemd/system/multi-user.target.wants/plexmediaserver.service.
Unpacking plexmediaserver (1.15.0.659-9311f93fd) over (1.15.0.659-9311f93fd) ...
Setting up plexmediaserver (1.15.0.659-9311f93fd) ...
Created symlink /etc/systemd/system/multi-user.target.wants/plexmediaserver.service → /lib/systemd/system/plexmediaserver.service.
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for ureadahead (0.100.0-20) ...
This latest update has broken a running plex server because it does not honor the defaults and installs into a pre-defined path.
It does not honor /etc/default/plexmediaserver and should consider it during installation and runtime. The following can be added to the top of the [service] section in /lib/systemd/system/plexmediaserver.service
EnvironmentFile=/etc/default/plexmediaserver
As for installation path that is another consideration that needs to be looked at. If the server is using something other than the static path in the package their plex install will break.
UPDATE: I resolved my issues by doing the following:
Since Aug 2016, when Ubuntu 16 was released with systemd, we migrated to it.
Initially Ubuntu/Debian had the location of the service file incorrect.
They have since corrected that error.
I have documented the standard way here.
The short form is:
sudo systemctl edit plexmediserver and place your customizations there
-or-
Manually create /etc/systemd/system/plexmediaserver.service.d/override.conf (systemctl does this for you as well)
Thank you for the clarification. I urge the package maintainer to add an EnvironmentFile within systemd to manage values separately from editing the main service unit. During installation this file can be validated by the user with a diff to show any updates or changes needed by the package manager. The idea being to separate out statically typed values from installation.
Today is your lucky day. I am one of the packaging maintainers here at Plex.
I can add migration support for carrying EnvironmentFile= specifications forward from older environments but some of those created in the early Ubuntu/Debian days have been problematic to manage. Problematic in that I also attempt some level of validation to ensure I am migrating the correct information forward.
I will definitely look further into the use of override.conf versus local.conf and see how systemd handles when both are present (one of the many problems I often encounter)
If I may clarify here. the contents of /lib/systemd/system/plexmediaserver.service will be overwritten with each update because these are under the control of the package manager.
Only those files in /etc/systemd/system/plexmediaserver.service.d are left untouched.
Caution must also be given; Should one decide to make any changes which impact how PMS starts or is controlled, other than Environment, User, Group, or Umask, any failure of PMS to start is the user’s responsibility. It is programatically impossible to understand every user’s configuration intent in the limits of package installation script.
No clarification needed, I completely understand. As stated, my hope is the package maintainer utilize EnvironmentFile in /lib/systemd/system/plexmediaserver.service and include an additional file for the defaults such as /etc/default/plexmediaserver or a similarly named default file. Users can then create their own /etc/systemd/system/plexmediaserver.service.d/override.conf if they desire to override the defaults as systemd interprets this file location to override the defaults.
What’s unclear to me is how service.d/* works in terms of order or keywords for filenames. This may also be something that’s not implemented in systemd yet. Such as ordering with 00-, 10- in other .d directories, or maybe it does work as I haven’t tested it yet.
Moving those items into a defaults file may assist automated upgrade applications and migrations between hosts. Not for all scenarios, but in my case it would have.
Essentially any item starting with “Environment=” and similar non-systemd specific variables such as the following:
Those INFO values are dynamically constructed as the shell executes.
We have those values sent up so I can keep track of how many configuration permutations exist.
I get a periodic report so when someone tells me there is “ABC problem” with something on platform A, OS distro B, I can immediately triage the impact it has
If I were to place them in an Environment= string, they would not be evaluated. They would be passed into PMS in the raw, unevaluated, form you see there.
What I’m looking for are things like:
Ubuntu, 18.04.01, X86_64
Fron this, If there is a problem unique to a distro release, I can better focus on it rather than wasting time waiting and hoping to collect information.
UPDATE/EDIT: Tested to see if evaluation is done outside of /etc/default/ and it will work if the following file is used EnvironmentFile=/lib/systemd/system/tester.service.d/tester.conf
Further testing of override.conf, possible order of files evaluated in service.d would be interesting. Example test cases:
Thank you for that but we are actually working on a different mechanism.
In the near future, there will be no need for those variables as it will all be PMS internal.
