I use Plex as an example. If I want to ensure that always the latest build is installed, or plug-in updates are “comprehended” by the Rock-on, it would be nice to not to have manually stop and restart the Rock-On, but be able to schedule a periodic task that restarts a given rock-on so it can be used as a “set and forget” strategy. I know, that this might not always be the smartest thing to do, especially with new Rock-Ons that might have some stability issues with new versions, but for more mature releases (and their plug-ins) that would be a nice convenience to have.
Unless there is already a script or functionality for this that I am not aware of, or a better approach in general.
I like this idea… and considering how many Rock-ons use Linuxserver.io’s images (which usually check for and update when started), this could apply to quite a few Rock-ons.
Could this be “simply” done through a cron job docker restart [container name]?
This works on the container’s hex IDs rather than the names, but will pass the whole list to docker for restarting.
This could be run on a cron at say … 2am daily, using the full path to avoid any cron env limitations:
Only on the assumption that the container provider keeps the container itself up to date.
Many of these containers are provided by linuxserver.io, not the actual package maintainer - who in most (if not all) cases do not provide a first-party docker container.
As a result, it may be some time before the container is updated with the latest version.
Most containers provided by linuxserver.io have scripts in them that on start will check for and install the latest version of the applications in question - IE: the Plex container will (regardless of the plex version supplied in the container) check for plex updates and update Plex for you.
This has the added advantage of not needing to redownload the whole docker image (inc. busybox, etc), and only the application itself.
Disclaimer: This is as I understand it, I am not one of the contributors of the project at this time.
I have to check, but the online Plex update does not seem to always work if my memory serves me right, whereas as a restart seems to pull the updated container image - in the instances where I observed that, it looks like that the container was updated very quickly after a plex update was offered in the UI.
In my scenario, a manually updated add-on will only be recognized, when Plex is restarted. The add-on still requires the triggering of an update to be installed (via the UI), but it only becomes active once Plex has been restarted.
However, I think the other scenarios to get an updated container are valid, too. I was thinking about this feature request more on the User guided level - since I myself am not a script/Linux wizard. A UI based scheduled task would make it a user-friendly solution.
For sure, thank you for the ideas building on the original posting!
My Plex-container did an in-container update a while ago, unless I’m very wrong. I do know for sure that Sonarr and Radarr can do it to, and frankly, that’s what I’d prefer over restarting services to possibly trigger an update. If the app itself didn’t support it, I’d find out which script did the auto-update and call that with docker exec.
My experience is that the plex application will not auto-update on Linux, requiring the user to manually install the latest package and restart the service.
There may be something in the container performing this, but I’ve seen no evidence of it. Multiple times I have logged in to Plex, and seen an outdated version banner at the top. Restarting the container has solved this in each case, with linuxserver.io’s autoupdate on startup.
The applications Sonarr and Radarr can update themselves, as far as I’m aware this isn’t managed by the container.
While it is possible to do run the update inside the container container (IE: with “docker exec -it”), I’m not sure what command it uses to auto-update on startup.
Also, as it does inherently auto-update on startup, and the container is only running Plex, I have to wonder why I’d go through the trouble of manually running the update in the container, rather than restarting the container and letting it update itself.
You’re right, of course. That’s what I get for answering while undercaffienated. I mixed up “you can update the app while running, from within the app” with “the app will update itself periodically”.
For what it’s worth, the Plex container can be updated from the command line:
[root@rockbox ~]# docker exec -ti plex-linuxserver.io /etc/cont-init.d/50-plex-update
Atempting to upgrade to: 1.9.6.4401-53fa66811
2017-11-02 07:52:50 URL:https://downloads.plex.tv/plex-media-server/1.9.6.4401-53fa66811/plexmediaserver_1.9.6.4401-53fa66811_amd64.deb [107908936/107908936] -> "/tmp/plexmediaserver_1.9.6.4401-53fa66811_amd64.deb" [1]
(Reading database ... 11383 files and directories currently installed.)
Preparing to unpack .../plexmediaserver_1.9.6.4401-53fa66811_amd64.deb ...
Unpacking plexmediaserver (1.9.6.4401-53fa66811) over (1.9.6.4385-ef7796e43) ...
Setting up plexmediaserver (1.9.6.4401-53fa66811) ...
There might be a smaller window of service disruption when updating this way instead of just restarting the container, but yeah, it’s not going to be huge, and it’ll be easier to just restart a few containers than to figure out for each one how to auto-update them.
To get back to the original issue: it’d be nice if there was a way of doing a bit more with cron from the web UI. Maybe not a full blown crontab editor (although that would work for the power-users), but a slightly more extensible system of adding and managing tasks.
I agree that a more scheduling capabilities should be available, however I’m unsure of viable it is to maintain - mainly because everybody will have different ideas as to what they want to schedule.
If it were to happen, I think it would likely need to be a full-blown cron editor, perhaps with a share function or repo (similar to rockons with docker containers) that people could easily add, for the less advanced users.
Personally, I’d like to see a lot more power-user capabilities in the system, even if they were hidden away and only available after an ‘advanced mode’ switch with stern warnings.
Emphasis on “safely”. I like the generic editor, especially since I am not an advanced Linux user. And from a consumer standpoint, the simple vs. advanced mode would be a very good idea, so one could select still from a catalog of tasks (hopefully then including my request ) but also perform more complicated tasks, especially if they involved ones’ own scripts.
I would do it, but I’m afraid my skillset will not go very far in that respect.
I mixed up “you can update the app while running, from within the app” with “the app will update itself periodically”.