I’m attempting to use the RPM for the 1.15.0.659 update of Plex Media Server, to build a custom Docker image. However, this update appears to have added a requirement for systemd, which of course fails in a Docker image.
I’ve been building Docker images using the PMS RPM since 2015…why was it necessary to add this dependency now? And can it be removed again so that Docker installs will work?
Also, as a side note, systemd should never be a dependency for anything…if systemd is present, it can of course be used (and should be used), but why is a software application defining how a server’s startup procedures are managed? I’m not saying systemd isn’t the right choice 99.999999% of the time, but no single application should be making decisions for the entire system.
Yes, all RPM-based distros use systemd, for full system installs. However, systemd is not used for Docker containers. You’re ignoring the very important part of my post, which mentions that I’m having problems with a Docker image build.
Here’s what I get in my build:
Running scriptlet: plexmediaserver-1.15.0.659-9311f93fd.x86_64 9/10
Plex Media Server requires systemd. Please upgrade the Operating Sytem version
error: %prein(plexmediaserver-1.15.0.659-9311f93fd.x86_64) scriptlet failed, exit status 1
Error in PREIN scriptlet in rpm package plexmediaserver
error: plexmediaserver-1.15.0.659-9311f93fd.x86_64: install failed
Note that I am attempting to install the RPM in an image based on Fedora 29…so the OS requirement is met, but there is obviously no systemd.
Please correct your RPM to allow installation into a Docker image.
Sorry, I didn’t respond to your comment “as distributed for desktop/workstation/server, is not for Docker user”.
If this is really your answer, I’m very disappointed in Plex. I would encourage you to rethink what you’ve said, and how you’re approaching your distributions.
Docker is just a way to package a runtime environment and isolate that runtime from other processes. To say that you need a different installation for Docker than you do for other Linux servers is not a good way to look at this…your Linux distribution should work equivalently on a bare metal server as well as in a Docker image.
Also, let me reiterate that I’ve been building Docker images with Plex Media Server (using the RPM package) since 2015…I think since PMS 0.9.12-ish. You’ve never forced a requirement on systemd before, why was it necessary now?
I really don’t want to use the “official” Docker images (I have a variety of reasons), and I don’t think I should have to, if you would just package your RPM without the forced systemd dependency. Just use systemd if it’s there, and leave it alone otherwise…why is that not acceptable?
I’m sorry if you don’t think you have to but this what has been decided.
If there is indeed a flaw in this thinking, I will gladly make the case but I need to understand a lot more of the particulars.
First, so you are aware:
This upgrade required us to update to GLIBC 2.14.1 as our absolute minimum version. This singular requirement immediately obsoleted many older systems. It’s impossible, impractical, cost prohibitive, as well as holding back Plex from using newer technologies in our products.
None of the versions below PMS 1.3.3 will even communicate with Plex.tv This is a well known and established fact for some 2 years now. Therefore anything pre-1.0.0 cannot be introduced as supporting argument.
In August of 2016, both Canonical and Redhat switched to systemd. Concurrently, they updated the SELinux ruleset. We were forced to comply if we wished to run on those environments. For purposes of backward compatibility, it was decided to support init based systems as long as possible. Unfortunately the time has come when it’s no longer possible to support it.
OpenSUSE was in terrible need of an upgrading since 1.12.x. Because of all the compatibility problems, it was decided by senior management to support systemd only. I rewrote that installer. It is now being used in PMS 1.15.0. Only those OpenSUSE systems which support systemd can use the RPM.
5 . From Ubuntu’s own website, using their EOL data, will we will be removing init based support from all DEB desktop packages
Ubuntu 16.04.1 LTS Xenial Xerus April 2021
Ubuntu 16.04 LTS Xenial Xerus April 2021
Ubuntu 14.04.5 LTS Trusty Tahr April 2019
Ubuntu 14.04.4 LTS Trusty Tahr HWE August 2016
As you can see, Ubuntu themselves are issuing a full EOL status as of April 2019. Whichever version of PMS is available for those platforms when installer support is finally removed (approx 90 days later) will be the final version for them. Is it fair to expect Plex to support an OS which Plex can’t get support for?
Addressing your Docker issue:
Docker has a specialised s6-init which controls container start/stop activity. It falls completely outside the realm of regular init or systemd.
If you are copying the PMS package into the container and attempting to install it using dpkg or rpm, I can guarantee it will fail because neither of the desktop packages are configured to support Docker’s s6-init. I specifically query cat /proc/1/comm knowing it will return init or systemd . This guides my installation process. If I find neither, while the software might go to the right directory locations, it will not run because I have no way to link it in.
With this as base knowledge of how we got to today and where the near future will take us, please help me understand why it is required to be able to run a DEB or RPM inside a Docker container when a Docker Plex is already available. What merits “special circimstances”?
I understand everything you’ve listed, and I agree completely with advancing the base system requirements for running Plex Media Server. I’m not at all saying you shouldn’t use systemd or newer versions of any package. All I’m saying is that you’ve added a strict requirement for systemd, and it presumes that no other use-cases exist.
I notice that you keep referring to the RPM as the “desktop” package. Perhaps the problem lies here, i.e. you’re treating an installation of server software as desktop software. Plex Media Server might be installed on a desktop, but it is fundamentally server software. And servers come in many shapes and sizes these days, including Docker containers. If you need to distribute a desktop version of the software, then perhaps it’s time to split the RPM distribution into more than one flavour?
For “when a Docker Plex is already available”, I think you’re missing the point of Docker. Docker “official images” are not meant to be the one and only way to run software in a Docker container…in fact, this violates the principles of Docker. Official images are meant to be examples, kind of like reference implementations. But the image you produce and distribute doesn’t include things like the user I want to run Plex under, or any other runtime requirements of my environment. These aren’t “special circumstances”, they are just standard considerations for deploying software anywhere. I understand that many people will take the easier approach of using the official images…but this is really “lowest common denominator”, and I would encourage you to enable more than this.
Again, I want to reiterate that I’ve been running Plex Media Server this way for years now, and I highly doubt that I’m the only one in the world doing so. Building my own Docker image is something that allows me to control my runtime environment, which is the original primary purpose of Docker.
To add a reference, see Docker’s documentation on official images:
Nowhere in this description does it say that official images are intended to be the only way to run an application. All of the wording on the page is oriented towards an official image being a “starting point” and for “new Docker users”. The phrasing is about treating official images as a minimum for users who don’t want to go to the trouble of maintaining their own images.
RPM and DEB packages are to be used on native installations of Redhat and Debian Linux host OS platforms.
Docker is an abstraction layer which sits on top of the host OS. This means the Plex Media Server running in the container is two layers abstracted from the hardware not one.
If you want to make your own container, that’s perfectly OK.
If you think you continue to think you will be able to install any RPM or DEB directly into a Docker image, you clearly do not understand how it works.
I am very sorry but:
Use the official docker image
OR
Extract all the pieces from an official package and make your own, unsupported, Docker image.
This is how it works.
There is no more to discuss here. You want something your way and there is no justification of changing everything just for one person.
Wow, that was an extremely ignorant response. If that’s how it is, I guess I have to live with it, but I’m pretty disappointed in this result. If you really think I’m the only one building a custom Docker image, then you are deluding yourself…this is absolutely not about wanting something “my way”, it’s about doing something in a reasonable way. I’m sorry you can’t see that.
This has been very illuminating as to what kind of organization Plex really is. Not great news, I guess.
I’m not breaking anything, and you seem to not be understanding (or possibly intentionally misinterpreting) most of what I’m saying. I don’t really know why you’re getting so bent out of shape…I’m a paying customer of yours, and you’re the one breaking my use-case. If anything, I should be upset with you, but all I’m doing is asking you to consider an alternate opinion to your own.
So, ok, one final time: systemd is not a requirement for Plex…it’s just one way to start the application. Your official Docker images are not the only way to create a Docker container for Plex…they’re just a reference implementation. My use-case is that I want to install your RPM packages in a Docker image to create a Docker container, and your strict requirement for systemd breaks that. I’m not the only one who builds a custom image for Plex…do a quick search in Github and you’ll find dozens of implementations.
And just to confirm what I’m saying, I used rpmrebuild to modify your RPM package, commenting out the check for systemd, and any call to systemctl…and once I do that, it installs and runs perfectly. I’ve been running the server all week based on that installation, with no problems at all. So systemd is really not a requirement of the application…it’s just a requirement of your installation script that you’ve chosen.
Thanks for your time. I hope you take a breath and look at what I’m really telling you…and if you can’t see it, maybe ask some of your colleagues to have a look and help out with this. But if that doesn’t work, I guess I’m stuck with my rebuild workaround.
You want to take a package, created for the desktop environment, which itself requires systemd, and place it in an init-based environment.
Thanks for telling me you’ve repackaged and found a solution which works for you.
I must now, unfortunately, notifiy you that since you’ve gone against how PMS is distributed, there can be no support because we have no idea what you’ve actually done. Did you change any libraries or other dependencies? You stated you’ve removed all the systemd requirements.
What else did you remove? We have no idea.
Building my own Docker image is something that allows me to control my runtime environment, which is the original primary purpose of Docker.