Problem/Justification
I have an app that is currently shut down because I am not using it right now.
I want to update it, but it won’t let me.
Update process can only be started for apps that are currently running, and apps can only actually perform the update when stopped.
Currently the process of updating a stopped app is:
step 1. start the app
step 2. tell it to update. it will now STOP the app before updating, and then auto-start it
step 3. manually stop it
the request is to skip all these and just update the stopped app while it is stopped. without running it. (or automatically run and then stop to reach the same state as it started from).
Alternatively, an update request could auto-start relevant apps before auto stopping them. whatever it needs to do.
The reason stated in that link is that the dev who explained why not is assuming a hypothetical ridiculously bad implementation. which is
step 1. automatically start the app
step 2. immediately force stop it BEFORE it finished booting to start the bootup process.
and concerns that doing so could cause file corruption due to improper shutdown of the container.
but… why in the world would you implement it that way?
The solution is to just NOT use the ridiculously bad implementation.
either:
A. stage the update without starting the app first
or
B. start, WAIT until it finishes deploying (truenas is fully aware of this and reports the current deployment state), only when it finishes deploying and is fully running start the update process.
The entire apps system is a “ridiculously bad implementation”, and I advise simply not using it. Just install Dockge or Portainer, and then install and manage all the rest of your apps within that. Neither of these have this ridiculous limitation, or many other problems the community app system has.
Pretty extreme words but I don’t really disagree. Anyone that lived through the debacle of Truecharts never wants to experience it again.
The problem is that everyone wants the tiniest, most obscure app running on their NAS at any given time and a simple, easy way to install, remove or update like any old windows app. But these aren’t simple apps and most of them should be in virtual machines which the Docker implementation handles fairly well.
So the compromise is to run anything as a custom app and do all the hard work yourself, not depending on Truenas for anything beyond just running the thing. Dockge helps. Portainer helps. In the core days I had a Debian VM running Portainer for all that stuff.
To the OP, you can implement all these different ways and just use Truenas as the substrate. It subtracts your existing problems and gives you new ones. Also prevents a repeat of Truecharts and the redditor battle that ended all that support. Truly, DIY is the best solution. The things you manage yourself will continue to be practical and as up to date as you want, you’ll just put in more effort. To learn more, find Servers at Home. Quality dude with a YouTube channel, website and wiki. He has a magnificent series on hosting the Arr stack, as one example.
I actually have a very different angle. I never lived through the debacle of Truecharts, and only have a vague idea of what it even is. I only started using TrueNAS in late 2024, starting with 24.10 (Electric Eel), so I never saw any of whatever came before.
I’m perfectly happy with using docker to manage all these apps, rather than having separate machines, or using VMs: it’s simpler and more efficient with resources and works fine for my uses. For me, TrueNAS is the base OS for my home server, not just a NAS: it runs Linux, it manages data with OpenZFS, and it runs various self-hosted applications with Docker. I’m quite happy with it overall, but not with the way TN handled its “community apps”. It’s of course just a UI and management layer on top of Docker, but IMO it’s really poor and has too many problems, because it tries to insulate users from just using docker-compose by sticking a layer in between, and then getting a small army of volunteers to manage their own builds of these apps instead of just using official builds from the various projects on dockerhub. The only real “value” this approach brings is not having to mess with docker-compose yaml code, and instead having to use some very limited menu of options that varies by app and what these volunteers want to make available. I just don’t see the point when I can use docker-compose directly and bypass the middleman.
So this is why I always suggest ditching the TN community apps and just using Dockge/Portainer. Also, this new “Dockhand” app looks very promising too. Dockge is OK but has some big limitations. Ideally, in my perfect world, TN would just dump this community app thing and basically integrate something like Dockge/Portainer/Dockhand into the TN UI, so I don’t need a separate app for managing docker-compose yamls.
This would go against iXs recent path of making Truenas/ZFS more accessible to the home user and also pushing changes in that direction in the devellopment of Open ZFS.
(RAID Expansion, AnyRaid , wifi support, webinstall,…). Things that enterprise users, or home users with an affinity to enterprise gear probably dont want and dont need.
