These may be issues/bugs - and if so I’ll log them as such, I didn’t see any existing issues to match either - but I wanted to ask first in case I’m missing something obvious.
When my stable subscription updated me to 3.8-11, I could not see the new Rock-ons (Discourse, Jenkins) even after pressing the Update button several times. They appeared only when I rebooted (disabled and re-enabled) the Rock-on service.
Owncloud never properly starts when the Rock-on service is restarted. I suspect the Owncloud container is being started before the database container is. I always end up manually starting them using the docker CLI.
Hi @pdenhaan, the two points are so well defined, it’s best to just create github issues. As you can see, forum posts get buried down fast.
(1) is strange but I’d like to try and reproduce, may be we are missing something. But the Rock-On/docker service is completely independent from the app profile update via the update button. It downloads .json files from rockstor.com, parses them, updates the data model and makes it available for the client(UI).
Here are the issues. Feel free to create new ones in the future especially for behavior that is clearly reproducible.
Currently, we use on-failure:5. So when the docker service starts, if a container exited with non-zero code, it will be restarted up to 5 times or until it starts successfully – whichever happens first. This doesn’t seem to be working well because the exit code is set by the app and so, not standardized. For example, say owncloud and btsync rock-ons are both running. If the service is stopped, owncloud is gracefully exits with exitcode 0, where as btsync exits with 137. And when the service started again, the current restart policy start btsync but not owncloud, because of it’s graceful exit(even as we just turn off the docker/rock-on service).
On the other extreme, we have btsync which always seem to exit with exitcode 137, whether it’s stopped explicitly or if the service is stopped. So btsync always starts up upon docker service start.
I think a better docker restart policy to use is unless-stopped. This policy is independent of exit codes that are set by individual apps. And those that are explicitly stopped will not be attempted to start again on docker service start whereas those that were not stopped explicitly will be. The one side effect to note is that, docker will attempt restart forever, though doubling pause time between each attempt. I think this is fine.