Describe the feature you'd like
Make the successful "stop" of the ContainerManager service optional, to allow for a graceful fail in certain flows, especially if the stop fails specifically because the service isn't started. (or perhaps needs to be killed)
Certain operations should proceed if ContainerManager is not currently running, for example, the restore operation.
What is the motivation for the feature?
When a user is 'broken' from, say, an update to 29.x, and their CM instance has either become unresponsive or fails to start completely, running sudo ./syno_docker_update.sh restore --backup <backup_set_name> fails because one of the operations is to stop containermanager from running. If it's not running or not responsive, the step will fail, and users cannot restore to a previous version.
This is also probably a good opportunity to take a step toward decomposing the monolith, and perhaps pull the "start", "stop" and "restore" operations out of the main file and into utility scripts / functions that can be choreographed by the parent script, or run on their own for advanced users.
What alternatives have you considered?
The alternative today is to either reconstruct the files by hand, or uninstall and reinstall CM via DSM, which will take the user back to the factory setup, and needs to again be updated back to their preferred version.
Additional context
Opening this because I think it might be a good candidate issue for a community contribution as a good first issue.
It's also quite possible that my statement isn't 100% correct, and that a restore DOES continue when the stop operation fails... although I suspect not.
Describe the feature you'd like
Make the successful "stop" of the ContainerManager service optional, to allow for a graceful fail in certain flows, especially if the stop fails specifically because the service isn't started. (or perhaps needs to be killed)
Certain operations should proceed if ContainerManager is not currently running, for example, the restore operation.
What is the motivation for the feature?
When a user is 'broken' from, say, an update to 29.x, and their CM instance has either become unresponsive or fails to start completely, running
sudo ./syno_docker_update.sh restore --backup <backup_set_name>fails because one of the operations is to stop containermanager from running. If it's not running or not responsive, the step will fail, and users cannot restore to a previous version.This is also probably a good opportunity to take a step toward decomposing the monolith, and perhaps pull the "start", "stop" and "restore" operations out of the main file and into utility scripts / functions that can be choreographed by the parent script, or run on their own for advanced users.
What alternatives have you considered?
The alternative today is to either reconstruct the files by hand, or uninstall and reinstall CM via DSM, which will take the user back to the factory setup, and needs to again be updated back to their preferred version.
Additional context
Opening this because I think it might be a good candidate issue for a community contribution as a good first issue.
It's also quite possible that my statement isn't 100% correct, and that a restore DOES continue when the stop operation fails... although I suspect not.