Since there is a certain discrepancy between normal PMS and dockerized PMS, the dockerized version should be adjusted to provide a better user expirience.
Some Users want the update notification beeing disabled: Disable Update-Reminders in Docker
But I personally would just like to get the update button to work.
As PMS updates on container start a very simple way to update a dockerized PMS is to reboot it. A lot of other containers also provide such functionality. But getting asked to manually āupdateā the container and then just providing a link to an image that will download as soon as you click on if not serving anyone.
So I would like to ask for a way to hasslefree update the container through the GUI/App. But ofc just the Serverowner should be able to do so.
Thanks in advance!
ć ¤
ć ¤
ć ¤
P.S.: feel free to adjust the category of this post, if something else fits better.
An app/process inside a Docker container can only restart itself (the app/process), but it cannot restart the entire container. The only way to restart the container itself from the inside is to grant an app permission to control your all your Docker containers by mapping the Docker socket (/var/run/docker.sock). However, doing this is a security issue and should not be given to containers willy-nilly. It would defeat the purpose of isolating apps in containers. Plex especially should not be granted access to the Docker socket.
I would actually argue for the opposite to get rid of updating the app when the container is restarted. Instead, standard Docker practice is to use versioned/tagged Docker images. A new static image should be built for every PMS version. This would require manually updating the container with the new image everytime (or automatically using something like Watchtower) instead of a simple restart to update. Having versioned static images also allows for downgrading/upgrading to specific versions instead of always being tied to the current version. Plex already does this with each public PMS versions, but it is not available for beta PMS versions.
My understanding of Docker images and containers (and correct me if Iām wrong) is that they are separate entities. When a Docker image is updated one needs to:
Stop the currently running container
Remove the container
Remove the old Docker image
Pull the new Docker image
Recreate the new Docker container
In my experience, if you donāt do all of that you donāt get the new version of the Docker image and your Docker container will be the same code. On my Synology, itās fairly easy to do this and I usually first export the containerās settings. This makes the last step easy.
I know there is some automation software to help with this such as the aforementioned Watchtower but I havenāt tried to implement that on my Synology.
Yep, that is correct standard practice for the majority of Docker containers (and what Iām suggesting Plex should be change to), but not the PMS Docker container. The Plex container is just an empty shell where PMS is installed inside it when the container is restarted. Plex already does this with each public PMS versions, but it is not available for beta PMS versions.
Wrong. The behavior you are describing here is limited only to the public and beta tagged images. The latest tag has always pointed to an image which is also tagged with an explicit version that doesnāt change the version of PMS included in the image.
Ah, yes, my apologies. I run the :plexpass tag for testing which is where I get that behaviour. Itās the only way to get the beta PMS versions using Docker.
Iām confused. As I understand it a Docker container is an instantiation of a Docker image. As such restarting a Docker container will not get you a new version of the Docker image. The new version (:latest, :plexpass or whatever) needs to be pulled in order for you to instantiate a new Docker container with different code. I fail to see how āPlex should change to [this standard practice of re-instantiating a new container based on a new image]ā. As a purveyor of a Docker image, I would think that the management of that image and the instantiation of new containers would be the responsibility of the server owner, not the Docker image purveyor. Perhaps Iām not understanding this properly.
Ah, so this is not really Plex running in a Docker container rather itās a Docker container that monitors and updates the Plex software outside of the Docker container.
Personally, Iād rather control when and where I decide to update PMS.
True that, but you can exit/terminate the docker, like you can when you run into a problem. When your docker is set to āalways restartā it would update automatically. Even if that would not work, I donāt even want to reboot/restart the container, the request is more focused on updating the App semi-automatically (on Click).
Anyway I will modify my request a little and ask for a way to use the integrated update button, which then will (not restart the docker) but update the Plex App in the docker automatically which probably is faster anyway then rebuilding the whole container.
Anyway I think there should be a way to update it through the interface, otherwise it makes no sense having the button there.
I think the processflow should be like this:
If Update available: Download new App
If Step 1. was successfull: validate the file by hash (md5, SHA1, etc etc)
If Step 2. was successfull: stop old App
If Step 3. was successfull: install new App
DONE
So the container does not need to reboot/restart, all should happen inside the container. But the problem is, the click on the button atm is not usable, nor can other forks/images use him. That is a problem I think.
It is even easier than you think on a Syno-NAS: just pull the new image, stop your plex container and apply the āresetā action on it. As a result the existing container will be recreated based on the new image version. This is a feature of the Syno-UI and not available in vanila docker.
I am not sure how you come to this conclusion, but the PMS process is running inside the container.
If the PMS instance is running: PlexWeb will indicate a new available version.
If the Plex container is starting: the entrypoint script of the container will compare the installed version with the latest available version. In case the latest available version is different, it will download it, install it and then start PMS using the updated version.
I assume in s6-overlay the PMS process is the main process, that if terminated results in the container beeing terminated. If this is the case, then an in-place update wonāt be possible.
My understanding of Docker is that with Docker you create an image which is a layered file system in which you compose all the pieces of software you need for the container to run your app. As such I cannot envision how a Docker container can really alter itself and still be a Docker container. Sure I guess a Docker container could dynamically install new, different, patched software and/or do whatever it wants once it starts running. But to me, this new container is not that which was instantiated from a Docker image. Perhaps Iām getting a little too literal here.
I had had difficulties with Synology GUI and updating Docker containers. I guess itās just that the Docker container reset of Synology isnāt well documented what exactly reset does. All I found was āYou can start, restart, stop, force stop, reset, or delete a container. Please note that once you reset or delete a container, you cannot recover its data.ā It doesnāt even differentiate between delete and reset. I tried reset in the past and couldnāt figure out exactly what it was supposed to do. And when I went back to the Docker container it still complained that it was not up to date. It may be that I didnāt pull the newer image (though I would have sworn I did).
Thanks for the explanation though. Next Docker container update I will pay close attention and see if it really works that way for me.
Correct. An image consists of a manifest and all the image layers referenced in the manifest. The Storage driver, which usualy is overlay2 these days, is used to āmergeā the layers to present the view on the layered filesystem. It marks files existing in a parent layer, but deleted in a later layer as deleted, and files that are updated in a later layer as modified. The original files still remain in the parent layers (a layer is immutable). Finaly the container filesystem merges the layers of the image + a container private copy-on-write layer and uses it for the container.
You can do inside the container filesystem whatever your heart pleases. When the container is removed, all those changes into the containers filesystem are then gone as well. If you create a new container based on the image, of course it will start with the original state, and if the Plex image provides autoupdate, it installs the latest PMS version during first start and starts it then.
The docker way indeed is to create patched imags. Though, the PM autoupdate is a feature provided by the entrypointscript of the image, which kicks in before PMS is started. So the part beeing dirty would be if the downloaded .deb package or the installation it does would be stored in the container filesystem instead of in a volume or /tmp.
I am afraid you are right
In both cases the container filesystem is deleted. But Instead of just highlighting the consequences, they should have explained what it actualy does. Itās a docu āfailā as this feature realy is unique to Synologyās docker distribution.
So I just received a notification that thereās a PMS update and Iām eager to try it out on the Docker container. Problem is Iām away on business and canāt get to my Plex server to do this until I get homeā¦
So, I restarted the container and it updated with no problems. Nice.
But that got me thinking. Since I got notified there was an update in Plex Web why couldnāt it tell the PMS to reinstall itself with the newer version and restart PMS in the docker container without requiring the user to restart the docker container? Of course, there could be some config to say whether the user wants auto-update or manual update?
Your use case will likely be different but here is mine.
I have Plex running on my OMV server in the linuxserver/plex docker, but it wouldnāt matter if I was running the plexinc/pms-docker image instead.
On my Linux Mint 20.3 desktop I have an application launcher that runs the following command:
ssh fred@omv ā/usr/bin/docker restart plexā
which restarts the container and if an update is available it will be applied.
Clicking the desktop icon is no more difficult that clicking on some similar button within the Plex web GUI. And itās easier than SSHing into the server to restart the container.
Hmmā¦ā/usr/binā in the ssh command before docker is unnecesary. Also āitās easier than SSHing into the server to restart the containerā ā but you are SSHint into the server to restart the container! You just did so in a shortcut.
Plus if the container would restart itself when sensing an update then youād even eliminate the last button to click!
