Update to plexmediaserver 1.7.4.4017 in ubuntu fail in post-install script.

[tcdiem]

Hello,
I have a ubuntu environment, reunning 16.04.02 LTS. I have installed Plex Media Server 1.7.3.3937. When upgrading to 1.7.4.4017, I have the following (in the example, I’m retrying a failed installation, thus the versions are the same):

    # dpkg -i plexmediaserver_1.7.4.4017-3886b5c85_amd64.deb
    (Reading database ... 20780 files and directories currently installed.)
    Preparing to unpack plexmediaserver_1.7.4.4017-3886b5c85_amd64.deb ...
    Unpacking plexmediaserver (1.7.4.4017-3886b5c85) over (1.7.4.4017-3886b5c85) ...
    Setting up plexmediaserver (1.7.4.4017-3886b5c85) ...
    dpkg: error processing package plexmediaserver (--install):
     subprocess installed post-installation script returned error exit status 2
    Processing triggers for ureadahead (0.100.0-19) ...
    Processing triggers for systemd (229-4ubuntu17) ...
    Processing triggers for mime-support (3.59ubuntu1) ...
    Errors were encountered while processing:
     plexmediaserver

On /var/log/syslog:
Jun 27 12:45:32 bromum systemd[1]: [/etc/systemd/system/plexmediaserver.service:11] Invalid escape sequences in line, correcting: “/bin/sh -c ‘LD_LIBRARY_PATH=/usr/lib/plexmediaserver /usr/lib/plexmediaserver/Plex\ Media\ Server’”
Jun 27 12:45:32 bromum systemd[1]: [/etc/systemd/system/plexmediaserver.service:11] Invalid escape sequences in line, correcting: “/bin/sh -c ‘LD_LIBRARY_PATH=/usr/lib/plexmediaserver /usr/lib/plexmediaserver/Plex\ Media\ Server’”

Rolling back to 1.7.3.3937-70f781325 works fine.

[mdnitoil]

I’m sure you’ve probably checked this, but when that happens to me it’s due to a corrupt download.

[tcdiem]

@mdnitoil said:
I’m sure you’ve probably checked this, but when that happens to me it’s due to a corrupt download.
IMHO a corrupt download would issue a different error when dpkg is extracting the package. Still I’ve just double checked and SHA-1 checksums and the file matches from download page, so no corrupt download in my case, but still thanks for pointing it out.

[tcdiem]

Just to point out that seems a bug introduced in the 1.7.4 release.
Diff’ing the 1.7.3 version against 1.7.4 version

11c11
< ExecStart=/bin/sh -c 'LD_LIBRARY_PATH=/usr/lib/plexmediaserver /usr/lib/plexmediaserver/Plex\ Media\ Server'
---
> ExecStart=/bin/sh -c 'LD_LIBRARY_PATH=/usr/lib/plexmediaserver "/usr/lib/plexmediaserver/Plex Media Server"'

Would be nice if a dev checks this or if someone bump a dev. I can of course edit the script myself and repack the deb file, but kinda defeats the purpose.

[mdnitoil]

Thanks for pointing out the problem. I’m running 16.04.02 myself, so I’ll be monitoring this thread before attempting an upgrade.

[tcdiem]

So, after repacking, I’ve found the actual issue. The mentioned “escaping error” was autocorrected by systemd (although imho it should be fixed anyways) but in the actual post-install script of the 1.7.4 version, the following lines were added:
95,98d94
< # Ensure we load the udevrule and trigger for any already inserted USB device
< udevadm control --reload-rules
< udevadm trigger
<

When triggering the post install script with sh -x, I see the following:
…
+ [ 1 = 0 ]
+ [ -f /etc/systemd/system/plexmediaserver.service ]
+ sed -i /Environment=LC_ALL=en_US.UTF-8/d;/Environment=LANG=en_US.UTF-8/d /etc/systemd/system/plexmediaserver.service
+ udevadm control --reload-rules

Which means that ‘udevadm control --reload-rules’ is the one throwing return code 2, which is not handled by the script itself and it throws it back to dpkg. Adding an ’ || exit 0’ at the end of the offending line silents the non-zero return code.

From udevadm manpage (https://linux.die.net/man/8/udevadm):

–reload-rules
Signal udevd to reload the rules files. The udev daemon detects changes automatically, this option is usually not needed. Reloading rules does not apply any changes to already existing devices.

Since I don’t know the reason why the udevadm commands were required (and if retcode 2 is expected or can just be ignored), I will leave it for someone with insight to answer what would be the best approach to address it.

[ChuckPa]

@tcdiem said:
Just to point out that seems a bug introduced in the 1.7.4 release.
Diff’ing the 1.7.3 version against 1.7.4 version

11c11
< ExecStart=/bin/sh -c 'LD_LIBRARY_PATH=/usr/lib/plexmediaserver /usr/lib/plexmediaserver/Plex\ Media\ Server'
---
> ExecStart=/bin/sh -c 'LD_LIBRARY_PATH=/usr/lib/plexmediaserver "/usr/lib/plexmediaserver/Plex Media Server"'

Would be nice if a dev checks this or if someone bump a dev. I can of course edit the script myself and repack the deb file, but kinda defeats the purpose.

You called? This is my work.

What’s up with this?

The \ was fixed because Ubuntu finally stabilized on what works for them. It’s only Ubuntu which needed the escaping exception.
After removing the backslash, it was tested on Ubuntu, Fedora, Debian, and Centos

[ChuckPa]

Having double checked 16.04.02 LTS, I cannot recreate this error.

Do you have a /etc/systemd/system/plexmediaserver.service file with customizations in it?
If so, the correct method for modifying PMS configuration is

 /etc/systemd/system/plexmediaserver.service.d/
  override.conf

where override.conf contains, as example:

#
#
[Service]
Environment="PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR=/path/to/some/new/Application Support Directory"
User=nnn
Group=ggg

Observe Spaces are permitted within the single set of double quotes.

My installation of PMS 1.7.4 is as follows:

Let’s figure out what the difference is.

[tcdiem]

Hello ChuckPA,

I appreciate the efforts to narrow this issue. I understand the reasoning behind the removal of the backslashes from the service file and can confirm that besides that warnings in the syslog, no other issue have arisen from it.

I don’t have a custom postinstall script.
As I’ve mention before, I believe the issue is the retcode of “udevadm control --reload-rules” which is the only place which I get a retcode 2. Even running it as root on my box makes it return 2 (not 0). I haven’t investigated why it doesn’t return 0, as plexmediaserver seems to be the only package which is throwing me errors due it. (checked afterwards maybe because I run it in a container and udev isn’t running? )

This can be further reinforced by the output attached of the “sh -x” run of the postinstall script by hand.

If I edit the postinstall script at /var/lib/dpkg/info/plexmediaserver.postinst and add a ‘|| exit 0’ so postinstall will never return error if the udevadm fails or not, you can see that the installation proceeds just fine. in the second screenshot:

Since I don’t know the reasoning behind the need to force udev to reload its rules and if an issue in the reload should cause the package to not be installed cleanly, I would suggest to either catch the non-zero retcode from it (by ‘|| exit 0’) or use a more complex mechanism if you so desire to not silently just continue.

This way the package itself won’t be left in a broken (or partially-configured) state due a non-critical command in its postinst script.

[tcdiem]

Just as a note for anyone else landing in this thread. My suggestion of ‘|| exit 0’ was not the best approach but instead a means to suppress any problem in postinst script by making it stop there and exit without errors.

A more sensible approach (which won’t interrupt the script but simply continue executing it) would be using ‘|| true’ instead.

[ChuckPa]

Cool! Thank you. I’ve been chatting with the Dev who heads distribution packages for all the platforms. He’s seen (on netgear specifically) where a previous package install can cause a false error code in a subsequent.

Since you can replicate but I can’t for whatever reason, would you consider uninstalling the package (not a purge), reboot, do the apt-get update/upgrade cycle, then install 1.7.4 clean as if fresh and check it’s retcode ($?)

[tcdiem]

I’ve done your tests, but to cut the story short, I believe the issue on netgear is different than the one I’m having. If you want to reproduce my situation, you just have to make sure that udevd is not running when installing or updating plex (hence ‘udevadm control --reload-rules’ will start throwing you a retcode 2).
I might be able to help with debugging the netgear issue but I think it should be in a different post

So, as you asked, I’ve removed (not purged) plexmediaserver package, stopped the container entirely and started it (reboot). Once the container was up, i’ve attached to it and attempted to install plexmediaserver package.

It was with the same result, because my container doesn’t run udevd (it is a container, it doesn’t need it. And it shows that even if I run manually ‘udevadm control’ without a udevd running, it will throw me a retcode == 2, which should be your starting point to reproduce my issue):

As illustrated before, if I don’t have a udevd running, the postinst script will fail with a retcode == 2:

I’ve then created a patchfile containing a fix, more along the lines of how your devs have written the postinst script itself (so no hacking it away with ‘exit 0’), which can be seen in this screenshot as ‘cat /tmp/check-for-udev.diff’. I’ve then repeated the same process as above (remove plexmediaserver, stop the container, start the container, install plexmediaserver - which fails with same error - then applied my patch to the postinst script and then attempted to configure it, which was successful:

My patch, as seen above, tests if /sbin/udevadm binary exists and if udevd is actually running. Only if it is, it will trigger the udevadm commands.
Since in my case udevd is not running, they will be skipped thus no errors issued. This can be seen by running the postinst script with ‘sh -x’ as follows:

In my humble opinion, I would still prefer a solution more along my previous ‘|| true’ comment, since imho the case (by the comments and this script) for triggering a reload would be for re-detecting any additional disk device and creating/detecting the devices related with hwaccel (/dev/dri, video0 and fb0). I fail to see why the installation of the package should fail (and left in a broken state) if you can’t trigger the reload of udev rules when the package is installed.

My patch adds the need of the ‘pgrep’ binary, which might be undesirable (and another point for making udevadm commands never fail with ‘|| true’). If you are really greatly concerned about silencing it and maybe overlooking a potential issue in the future, you can always log the error or print it in the stderr (something like this):

I hope this have been helpful.

[tcdiem]

I was curious on how other important packages that uses udevadm handles the possibility of udevd not running on installation time.
From the packages I have in my host machine (not in the plex conainer):
pulseaudio.postinst: if ! which udevadm >/dev/null 2>&1 ; then
pulseaudio.postinst: udevadm control --reload-rules || true
pulseaudio.postinst: udevadm trigger --subsystem-match=sound --action=change|| true

and udev itself
udev.preinst: udevadm control --log-priority=0 || true

[ChuckPa]

Cross-posting / Linking now-closed thread which contains useful information while the Dev and I work on this issue

Debian Package for version 1.7.4.4017 requires udevadm but doesn't install it.

[ChuckPa]

Folks,
Thank you ALL for your work.

I found it and know where it’s going sideways. I don’t have permission to make the correction myself so have written it up for the Dev to make the change.

[StSimm1]

Fixed in 1.7.5

[papertigers]

@StSimm1 said:
Fixed in 1.7.5

Still seeing the issue over here.

root@plex:~# dpkg -i plexmediaserver_1.7.5.4035-313f93718_amd64.deb
(Reading database ... 36431 files and directories currently installed.)
Preparing to unpack plexmediaserver_1.7.5.4035-313f93718_amd64.deb ...
stop: Unknown instance:
Unpacking plexmediaserver (1.7.5.4035-313f93718) over (1.7.5.4035-313f93718) ...
Setting up plexmediaserver (1.7.5.4035-313f93718) ...
dpkg: error processing package plexmediaserver (--install):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for mime-support (3.54ubuntu1.1) ...
Errors were encountered while processing:
 plexmediaserver
root@plex:~# cat /etc/issue
Ubuntu 14.04.5 LTS 
 \l

and for good measure

root@plex:~# dpkg -r plexmediaserver
(Reading database ... 36431 files and directories currently installed.)
Removing plexmediaserver (1.7.5.4035-313f93718) ...
stop: Unknown instance:
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for mime-support (3.54ubuntu1.1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
root@plex:~# dpkg -i plexmediaserver_1.7.5.4035-313f93718_amd64.deb
Selecting previously unselected package plexmediaserver.
(Reading database ... 33264 files and directories currently installed.)
Preparing to unpack plexmediaserver_1.7.5.4035-313f93718_amd64.deb ...
Unpacking plexmediaserver (1.7.5.4035-313f93718) ...
Setting up plexmediaserver (1.7.5.4035-313f93718) ...
dpkg: error processing package plexmediaserver (--install):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for mime-support (3.54ubuntu1.1) ...
Errors were encountered while processing:
 plexmediaserver

[papertigers]

Looks like 16.04 works fine.

Accidentally deleted the wrong instance . Looks like I am going to have a fresh start, too bad I lost watch history.

[MichaelDygme]

I’m using unraid and have no clue on updating the PMS docker. Is there even a way to perform that? It should follow other docker rules on unraid, when there is an update it should indicate on the unraid portal page there is an update. Apparently PMS isn’t taking that route and going to make this a time consuming process for people that don’t use the command line a lot?

[ChuckPa]

@opentoe@gmail.com said:
I’m using unraid and have no clue on updating the PMS docker. Is there even a way to perform that? It should follow other docker rules on unraid, when there is an update it should indicate on the unraid portal page there is an update. Apparently PMS isn’t taking that route and going to make this a time consuming process for people that don’t use the command line a lot?

You should find Docker-Plex in the registry as #latest. Update your Docker container and/or image in whatever manner is appropriate for your local configuration.