I have two issues with my Plex fedora package. First, after installing an update, my /etc/yum.repos.d/plex.repo file is modified so that “enabled = 1” is changed to “enabled = 0” which means that I’ll never get any more updates. Additionally, the service doesn’t restart automatically after an update.
Neither of these are huge problems, I guess, but I have my system set to upgrade Plex automatically, and after the first update it all breaks down. I could write a script to fix it, I suppose, but it doesn’t seem like it should do these things in the first place. Am I missing something here, or is this a bug?
I know it’s annoyance. It’s currently done this way to give you the opportunity to download the file and save it first. Yum doesn’t let us save the downloaded file. If you check in the yum/dnf database (/var/lib) you’ll see where it downloads and installs from /tmp
Until such time as we’re permitted to roll back to a previous version of PMS, this was determined to be the safest default course of action to take.
If you want, you can always setup a nightly cron job to enable the repo.
What about my second question: why does updating not restart the media server?
As for the first thing, I see what you’re saying, but I think this is incorrect behavior. First, it is unlike all other software, so for someone like me that is used to Linux administration, it is completely unexpected. Second, people who don’t have confidence in your releases can always download the RPMs manually. Third, and most worryingly, it seems to indicate that the Plex team doesn’t have confidence in their own releases. If it’s a release, presumably you’ve tested it. Do you think it’s going to break every time? If so, should I not be using your Linux server? Is it a beta? Fourth, a sophisticated user, who is enabling repos and so-on isn’t going to mind uninstalling and reinstalling an earlier RPM that they’ve had to download if a new one breaks things. Presumably an unsophisticated user is just downloading an RPM each time and double clicking it to install.
Basically, I think if you’re going to have an RPM repo, it should behave like an RPM repo. If you don’t want people to update every time, then either (a) test more carefully until you have confidence it your releases or (b) just don’t have a public repo.
Anyway, those are my reasons for thinking current behavior is incorrect. I had another one, but I got distracted in the middle of this and forgot it.
Also, by default, the service does not automatically start. Whatever state it is in, remains.
There was a great deal of ‘back & forth’ from the community; those who want it to autoenable and autostart on Linux versus those who don’t.
The primary driver for not autostarting is to allow creation of a service definition override / overriding default parameters.
Once enabled, it will stay enabled and autostart after each reboot.
@ChuckPA said:
I know it’s annoyance. It’s currently done this way to give you the opportunity to download the file and save it first. Yum doesn’t let us save the downloaded file.
If you wanted to do that, then it’s simple. Just DON’T set the flag to 1. If someone does set the flag, then that means they DO want the update facilities provided by their distro, so leave that choice to the user and don’t try and second-guess them.
Hm, I must be missing something because my plexmediaserver service is not restarting. I used systemctl to enable it and start it, but after the update it needs to be started again by hand. Am I missing a step?
when you systemctl enable plexmediaserver and reboot, it better start else you have a bigger issue with the host.
I’ll go back an talk with the dev about seeing how he feels about preserving the state of the flag. To do so does require I parse the existing (if exists) and then update after. Not a big deal but if we’re going to do it, it must be supportable across all the platforms.
I am NOT saying you must reboot. I am expressing how systemctl (SystemD) works. When enabled, SystemD will autostart the service.
If you wish to be 100% certain after an update, perform the update and then restart the service (which I am also working on how to coordinate across all the different distributions and supported versions)
I’ve thought about this further. I’ve also chatted with my contact in Engineering. I can make the change to restart the server when PMS is updated.
If I make this change, it will occur regardless of the current streaming activity. It will not be able to detect any PMS activities. The end result is any playback currently occurring will be interrupted while PMS restarts.
For me, yes. When I update a service I expect it to restart. If I don’t want it to restart, I don’t update it. After all, the service stops anyway during an update. The only question is whether or not it will start up again.
So, I’m confused because a couple of things you’ve said don’t jibe with my Fedora 25 experience. My experience is that no matter what the before state is, and no matter what the systemctl settings are, the service stops for the update and stays stopped.
I don’t mind pedantic. It’s good to be thorough. I would say:
Get state of plexmediaserver, S
Perform update
Set state of plexmediaserver to S
I mean, that’s what I’d like personally, but I realize that I’m not the only Plex user!
I have changed the RPM spec file to not replace /etc/yum.repos.d/plex.repo if it exists.
This preserves its state. If you have enabled the repo, it will remain after PMS update.
I’ve spoken with the dev who will review it. It’s a trivial change. I suspect it will go into the next build but have no formal commitment from engineering yet on that.
Did this ever happen?
yum update works and updates plex, but then I have to restart plex manually. This should happen automatically as part of the update.
