In order to restart itself, a container would need to have access to the docker.sock (this was addressed in the very first response…), which might appear like a beginners dream, but for everyone else it’s an unnecessary security risk.
Without the docker.sock, the only thing a container can do is end itself. For those that use a restart-policy, the container would restart again and perform the update. Now imagine how confusing it must be for users that didn’t create the container with a restart policy and suddenly have a stopped container… just because they clickend an “update” button.
OCI Containers are not designed to provide in-place updates of the main application. Maybe you guys are better of with lxd/lxc, that virtualizes an os in a container, instead with docker which virtualizes an application in the container.
Begin with pulling the image. There’s no reason to kill the container and then wait to download the new image. Pull the image first and then when you stop/delete/recreate, if someone is watching something, they won’t even be interrupted because the server is back up and reestablishes connection before the buffer runs out on the client.
Not sure why access to the docker.sock is required. Couldn’t the running PMS in the container sense that there’s an update, perform the appropriate installs then arrange to restart itself?
I previously just installed watchtower in another docker container and it will check daily for a new image and if needed it will pull the image, update and restart the container. I run other apps on docker and it works fine. It should in theory work fine with Plex as well.
Not realy “dockeresque”, but it could spawn a new process that takes care of this, which at one point will have to stop the existing pms process and start a new one. I doubt that the container will survive a stop/start (aka restart) of the pms process, as it’s bound to a specific process id, which will change as you want to replace the binary used for the process.
There is a reason why many applications that provide in place updates, disable it for containers and ask to update the image instead.
From what I know about 8 years of dealing with containers… this is tricky and if possible will high likely result in an uclean solution.
There is a reason why the container updates the pms version BEFORE it starts the pms process. The update part is done in the entrypoint scripts befoe the main service is started. Once the main service is started, it determines the lifecycle of the container.
Like I said: it makes most sense to make the update button stop the container, and let a restart handle the update.
Update: two different approaches are discussed in this thread. Auto update for the public/plexpass tag AND container updates thru image updates (pull image /remove container /recreate container manually or with watchtower). Actualy the later approach is the cleaner one, but I am uncertain if beta/plexpass versions are available that way.
Wouldn’t the solution to that be to write a parent process that doesn’t get restarted but rather manages the PMS process, replacing it when it needs updating? Seems clean to me…
The whole discussion made me switch to the watchtower + latest tag approach. Also the image, the latest tag points to (which right now is the same as the 1.27.2.5929-a806c5905 tag), has no high vulnerabilites ( 0 vs. 9) and in general less medium (22 vs. 84) and low (31 vs. 74) vulnerabilites. The vulnerability aspect alone is reason enough to replace the container with one based on a new image.
The whole concept of the public and plex-pass tag is not dockeresque, as the os packages of the image itself are not patched for a long period.
Regarding your wrapper idea: Surem if they got signal handling between parent and child processes right and would handle the child signals correct, then it would work. You do whatever makes you happy For me the watchtower + latest approach is the cleanest available solution, even though it means I will have to pass on the beta releases - I don’t realy care about them.
I ATM do something similar, and I know that it works like this, but it really should not be required to restart a container or anything to update the container, they have an update button and they support docker but these two don’t play well together… what a shame.
need to be said, that updatePlex.sh exits with error if it can’t pull new updates.
Why this way?
If an update for the docker-image is available it will docker-compose pull && docker-compose up -d and therefore restart anyway.
If no update available it will just restart without updateing the docker-image, but just the plex application.
I don’t like all these workarounds tho. I think this is just yet another example how many flaws plex does have, while beeing a paid applicatin!
For me the watchtower + latest approach is the cleanest available solution, even though it means I will have to pass on the beta releases - I don’t realy care about them.