Where did that file come from? It isn’t even a complete name.
It’s just whatever the latest release as of this morning is renamed to.
Filename makes no difference - output is the same.
I hate to remind, but it needs to be restated, OMV isn’t a supported distro.
I have never been able to make PMS work on it.
The OMV forums. plus a few here, have demonstrated how.
There is a user-contributed How-To in the server-linux-tips but that is the extent.
Ref to other thread: Plex on OMV4
I need to know more.
You’re running the 32 bit version in 18.04.
What is the CPU in the machine? It should not matter with a shell script but something is seriously amiss
It’s an intel q6600. The version I downloaded was definitely the 64-bit Linux version.
Could it be that I’ve had the x86 version installed previously and the x64 doesn’t want to upgrade over the top? I might just back up my config and purge the install to start again from scratch.
You can’t install the 64 bit version of PMS on a 32 bit OS.
The Core 2 q6600 is a 64 bit machine.
If you wish to use the machine in spite of its age, I recommend started the OS from scratch and going 64 bit.
You will not have any HW transcoding support because that CPU predates the technology.
Ref:
Since the new packaging script is used the package fails to install/upgrade on my system.
Debian 10 x64, fully updated, plexmediaserver installed from Plex’ APT.
$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
plexmediaserver
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 86.5 MB of archives.
After this operation, 403 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 https://downloads.plex.tv/repo/deb public/main amd64 plexmediaserver amd64 1.18.6.2368-97add474d [86.5 MB]
Fetched 86.5 MB in 7s (12.1 MB/s)
Reading changelogs... Done
(Reading database ... 111438 files and directories currently installed.)
Preparing to unpack .../plexmediaserver_1.18.6.2368-97add474d_amd64.deb ...
PlexMediaServer install: Pre-installation Validation.
PlexMediaServer install: ERROR: Multiple configuration files found in \'/etc/systemd/system/plexmediaserver.service.d\'. Please correct and install again.
PlexMediaServer install: Files found are: /etc/systemd/system/plexmediaserver.service.d/security.conf
/etc/systemd/system/plexmediaserver.service.d/syslog.conf
PlexMediaServer install: Please correct this error and try again.
dpkg: error processing archive /var/cache/apt/archives/plexmediaserver_1.18.6.2368-97add474d_amd64.deb (--unpack):
new plexmediaserver package pre-installation script subprocess returned error exit status 1
PlexMediaServer install: Error: Plex installation configuration file could not be imported. Please seek additional help in our Support Forums
dpkg: error while cleaning up:
installed plexmediaserver package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/plexmediaserver_1.18.6.2368-97add474d_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
The error message makes this look like this is intended and not a bug?! Why would the package refuse installation if unit overrides are present? They’re the intended systemd-supported way to apply patches to service units and the package really shouldn’t care or even test for their existence.
Moving the plexmediaserver.service.d directory somewhere else, installing the package, then moving it back and restarting the server works fine. Please remove this incorrect check.
Would you help me understand the purpose of syslog.conf file in plexmediaserver.service.d serves?
syslog.conf contains:
[Service]
Environment="PLEX_MEDIA_SERVER_USE_SYSLOG=true"
This is described in the support wiki here under Syslog Option (Ubuntu 16 specifically).
And security.conf contains some hardening options:
[Service]
InaccessiblePaths=/opt/ /srv/ /mnt/
ReadOnlyPaths=/media/
ReadWritePaths=/var/lib/plexmediaserver/ /tmp/
ProtectSystem=strict
ProtectHome=true
NoNewPrivileges=true
PrivateTmp=true
Either way, debian standard is that packages may only place their files in /lib/systemd/system and not touch anything in /etc/systemd, as that location is only for user-installed unit files and overrides, used to override defaults from package-supplied units.
Note it would also be valid to override the plexmediaserver.service unit entirely by creating the file /etc/systemd/system/plexmediaserver.service which would completely hide /lib/systemd/system/plexmediaserver.service from systemctl
What I’m trying to understand is why you would have that in a separate override file instead of in the Plex override.conf
You and I seem to understand systemd differently.
As I understand it from reading the sources.
-
/lib/systemd/systemis the pristine copy - Unit overrides go in
/etc/systemd/system/<servicename>.service - Individual service element overrides go in
/etc/systemd/system/<servicename.service.d/override.conf
We went through all the gyrations with Ubuntu when they went to 16 and had them backwards (placing main services in /etc) which was against systemd standard.
Ubuntu 18.04.4 LTS on an Intel NUC with i3-6100U. Updates have always worked perfectly and I have not made any changes since the last update.
(Reading database ... 152896 files and directories currently installed.)
Preparing to unpack plexmediaserver_1.18.6.2368-97add474d_amd64.deb ...
Removed /etc/systemd/system/multi-user.target.wants/plexmediaserver.service.
PlexMediaServer install: Pre-installation Validation.
PlexMediaServer install: ERROR: Multiple configuration files found in \'/etc/systemd/system/plexmediaserver.service.d\'. Please correct and install again.
PlexMediaServer install: Files found are: /etc/systemd/system/plexmediaserver.service.d/local.conf
/etc/systemd/system/plexmediaserver.service.d/override.conf
PlexMediaServer install: Please correct this error and try again.
PlexMediaServer install: WARNING: "/var/lib/plexmediaserver/Library/Application Support" isn't owned by "plex", UID: 111. Found "vito" UID: 1000 instead. Continuing.
dpkg: error processing archive plexmediaserver_1.18.6.2368-97add474d_amd64.deb (--install):
new plexmediaserver package pre-installation script subprocess returned error exit status 1
Created symlink /etc/systemd/system/multi-user.target.wants/plexmediaserver.service → /lib/systemd/system/plexmediaserver.service.
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Errors were encountered while processing:
plexmediaserver_1.18.6.2368-97add474d_amd64.deb
local.conf has been deprecated. The distros are wanting override.conf which is the systemd 245 standard.
rename it and daemon-reload
Thank you!
Please let me know if you have any further difficulties with it
@ChuckPa Thanks for taking the time to go through this. I think we have mostly the same understanding of it. If you create /etc/systemd/system/<servicename>.service that will override the entire unit file, i.e. /lib/systemd/system/<servicename>.service is not loaded at all. So if you only want to inject some directives you use /etc/systemd/system/<servicename>.service.d/. All files in that location will be loaded in addition to the main unit file (which can be either in /lib/systemd or /etc/systemd).
systemctl status output might be beneficial here:
$ sudo systemctl status plexmediaserver
● plexmediaserver.service - Plex Media Server
Loaded: loaded (/lib/systemd/system/plexmediaserver.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/plexmediaserver.service.d
└─security.conf, syslog.conf
As far as I know there is no reason to call the file override.conf (or is that distribution-specific?), I thought it was best practice to give the drop-ins a descriptive name and separate different concerns into different files.
But again I don’t understand what purpose the check in the installer script serves at all. It shouldn’t be its concern to check anything in /etc/systemd.
EDIT: From systemd.unit manpage:
Along with a unit file foo.service, a “drop-in” directory foo.service.d/ may exist. All files with the suffix “.conf” from this directory will be parsed after the unit file itself is parsed.
Some guides even recommend using the priority-number-naming-scheme, e.g. <servicename>.d/10-concern.conf, 20-something.conf to determine the order they’re loaded in.
This fixed my issue and I was able to install the latest build! Thank you for your help!
I appreciate you taking the time to work through this with me as well. It’s much nicer to resolve in a calm manner.
My understanding of the override is:
- Drawing on the main variables defined in
/lib/systemd/system<servicename>.service - Change or add only those variables which are to be changed in
/etc/systemd/system/<servicename>.service.d/override.conf
I originally allowed any *.conf file. It was reported last week that some distros no longer accept local.conf (which has been deprecated). To avoid, if at all possible, providing support for all the systemd versions in existence out there, I opted to prune to the “being deployed” standard of override.conf as the sole Drop-In in the directory.
I am curious what Debian is doing as it’s the main upstream for what will become Ubuntu and Ubuuntu is the distro of choice for all the Windows users looking for a better way. (rolling eyes – haha).
To add,
The intent of the packaging is to pre-diagnose the obvious errors and avoid the countless hours wasted tracking down faulty override files.
I haven’t found anything about special semantics for the filenames override.conf and local.conf . override.conf is most often used as an example, because systemctl edit <servicename> will choose that filename for you. Do you have a link to some statement that local.conf is deprecated? From the documentation I read that wouldn’t make any sense because systemd doesn’t care about the filename other than it ending in .conf .
All documentation I can find says that all files ending in .conf will be loaded from the drop-in directory and that is the behavior I’ve seen from all my linux machines so far.
See:
- https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-Managing_Services_with_systemd-Unit_Files#brid-Managing_Services_with_systemd-Extending_Unit_Config
- https://wiki.archlinux.org/index.php/Systemd#Examples
- https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html#override-only-specific-option
- https://serverfault.com/a/840999
I can understand all except Redhat.
Please consider the systemd source code on github (snippet from grep)
[chuck@lizum systemd.363]$ grep -iR /lib/systemd/system .
./NEWS: - or move the shutdown script to /usr/lib/systemd/system-shutdown/
./NEWS: * A new tool /usr/lib/systemd/systemd-dissect has been added that may
./NEWS: * The testing tool /usr/lib/systemd/systemd-activate is renamed to
./NEWS: /lib/systemd/systemd-sysv-install. This needs to be
./NEWS: /usr/lib/systemd/system/ to /etc/systemd/system/ and editing
./NEWS: /usr/lib/systemd/systemd-readahead analyze /.readahead
./NEWS: * The systemd binary is installed /usr/lib/systemd/systemd now;
./README: SysV init.d script, it calls /usr/lib/systemd/systemd-sysv-install;
./docs/AUTOMATIC_BOOT_ASSESSMENT.md: invoke `/usr/lib/systemd/systemd-bless-boot bad` at any time to mark the
./docs/DISTRO_PORTING.md: `/usr/lib/systemd/systemd --test --system` for a test run
./docs/PORTABLE_SERVICES.md: locations, i.e. in `/usr/lib/systemd/system/` and `/etc/systemd/system/` and
./docs/PORTABLE_SERVICES.md: i.e. primarily /etc/systemd/system/ and /usr/lib/systemd/system/ within the
./docs/PORTABLE_SERVICES.md:/usr/lib/systemd/system/minimal-test.service # the unit file for the service, with ExecStart=/usr/bin/minimald
./man/systemd-backlight@.service.xml: <para><filename>/usr/lib/systemd/systemd-backlight</filename></para>
./man/systemd-bless-boot.service.xml: <para><filename>/usr/lib/systemd/system-bless-boot</filename></para>
./man/systemd-bless-boot.service.xml: <para>The <filename>/usr/lib/systemd/system-bless-boot</filename> executable may also be invoked from the
./man/systemd-localed.service.xml: <para><filename>/usr/lib/systemd/systemd-localed</filename></para>
./man/systemd-networkd.service.xml: <para><filename>/usr/lib/systemd/systemd-networkd</filename></para>
./man/systemd-pstore.xml: <para><filename>/usr/lib/systemd/systemd-pstore</filename></para>
./man/systemd-socket-activate.xml: <programlisting>$ systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting>
./man/systemd-socket-proxyd.xml:ExecStart=/usr/lib/systemd/systemd-socket-proxyd /run/nginx/socket
./man/systemd-socket-proxyd.xml:ExecStart=/usr/lib/systemd/systemd-socket-proxyd 127.0.0.1:8080
./man/systemd-system-update-generator.xml: <para><filename>/usr/lib/systemd/system-generators/systemd-system-update-generator</filename></para>
./man/systemd-veritysetup@.service.xml: <para><filename>/usr/lib/systemd/systemd-veritysetup</filename></para>
./man/systemd-volatile-root.service.xml: <para><filename>/usr/lib/systemd/systemd-volatile-root</filename></para>
./man/systemd.environment-generator.xml:<filename>/usr/local/lib/systemd/system-environment-generators/*</filename>
./man/systemd.generator.xml:<filename>/usr/local/lib/systemd/system-generators/*</filename>
./man/timedatectl.xml: Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
./man/timedatectl.xml: └─595 /usr/lib/systemd/systemd-timesyncd
./man/user@.service.xml:│ │ ├─6680 /usr/lib/systemd/systemd --user
./man/user@.service.xml:# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
./man/nss-mymachines.xml:vu-rawhide-0 692 ? /usr/lib/systemd/systemd
./man/nss-mymachines.xml:vu-rawhide-0 731 ? /usr/lib/systemd/systemd-journald
./man/nss-mymachines.xml:vu-rawhide-192 734 ? /usr/lib/systemd/systemd-networkd
./man/nss-mymachines.xml:vu-rawhide-193 738 ? /usr/lib/systemd/systemd-resolved
./man/nss-mymachines.xml:vu-rawhide-0 742 ? /usr/lib/systemd/systemd-logind
./man/nss-mymachines.xml:vu-rawhide-0 752 ? /usr/lib/systemd/systemd --user
./man/nss-mymachines.xml:vu-rawhide-1000 1630 ? /usr/lib/systemd/systemd --user
./man/sysctl.d.xml: RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge"
./man/systemctl.xml: Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
./man/systemd-coredump.xml: <para><filename>/usr/lib/systemd/systemd-coredump</filename></para>
./man/systemd-coredump.xml: <para><filename>/usr/lib/systemd/systemd-coredump</filename> <option>--backtrace</option></para>
./man/systemd-fstab-generator.xml: <para><filename>/usr/lib/systemd/system-generators/systemd-fstab-generator</filename></para>
./man/systemd-getty-generator.xml: <para><filename>/usr/lib/systemd/system-generators/systemd-getty-generator</filename></para>
./man/systemd-homed.service.xml: <para><filename>/usr/lib/systemd/systemd-homed</filename></para>
./man/systemd-journal-remote.service.xml: <command>/usr/lib/systemd/systemd-journal-remote</command>
./man/systemd-logind.service.xml: <para><filename>/usr/lib/systemd/systemd-logind</filename></para>
./man/systemd-machined.service.xml: <para><filename>/usr/lib/systemd/systemd-machined</filename></para>
./man/systemd-networkd-wait-online.service.xml: <para><filename>/usr/lib/systemd/systemd-networkd-wait-online</filename></para>
./man/systemd-portabled.service.xml: <para><filename>/usr/lib/systemd/systemd-portabled</filename></para>
./man/systemd-quotacheck.service.xml: <para><filename>/usr/lib/systemd/systemd-quotacheck</filename></para>
./man/systemd-rc-local-generator.xml: <para><filename>/usr/lib/systemd/system-generators/systemd-rc-local-generator</filename></para>
./man/systemd-run-generator.xml: <para><filename>/usr/lib/systemd/system-generators/systemd-run-generator</filename></para>
./man/systemd-sysctl.service.xml: <command>/usr/lib/systemd/systemd-sysctl</command>
./man/systemd-sysctl.service.xml: kernel parameters by invoking <command>/usr/lib/systemd/systemd-sysctl</command>.</para>
What I’ve found is the migration from /etc -> /usr/lib (/lib)
as well as override.conf
All the man pages above are pointing to /usr/lib versus /etc.
Might Debian be holding back a bit? This is important for me to understand first and foremost.
The “killer” question is:
" If both conf files specify User = as a valid override for User=Plex, and they are different, which one takes residence? "
