I have disabled the default docker-compose.service in and created my own service definition that has docker-compose.yml stored to /var/sota/storage/docker-compose/ folder.
This seems to work fine with torizoncore-builder.
But after installation at some point the disabled docker-compose.service is enabled and started (by torizonos?). Then two systemd services are controlling docker-compose.yml. It took a while to realize that disabled docker-compose.service was get enabled.
Q: How to prevent enabling of the docker-compose.service permanently?
Q: Is it possible to define a custom systemd service and related docker-compose.yml for torizoncore-builder so that the docker-compose.yml is copied to some other folder than /var/sota/storage/docker-compose/ ?
Q: How to prevent enabling of the docker-compose.service permanently?
You should be able to just disable it with systemctl you could do disable or even mask to be more extreme.
Is it possible to define a custom systemd service and related docker-compose.yml for torizoncore-builder so that the docker-compose.yml is copied to some other folder than /var/sota/storage/docker-compose/ ?
Well you can define a custom systemd service, but TorizonCore Builder will always package your docker-compose.yml to be in /var/sota/storage/docker-compose. That is if you use the typical bundle workflow. I guess if you use the isolate command in theory you could put the compose file elsewhere. But, that would just be the compose file it wouldn’t package your container images in this case.
May I ask for what reason you want to use a custom systemd service and want the compose file in a different location?
I have disabled docker-compose.service but it seems TorizonOS activates it for some reason.
My guess is that when I stop my “custom-docker-compose.service” that manages docker-compose.yml, some TorizonOS maintenance services will activate the default docker-compose.service to keep docker-compose.yml running.
One such situation is when a systemd service responsible for update Docker image versions. Then the “custom-docker-compose.service” is stopped and started with new Docker image versions.
The reason I want to have a “custom-docker-compose” service is that in the docker-compose.yml there are MQTT broker + Python containers communicating with each other.
I have defined separate docker network to be able to start additional Python container into shell so that it has access to the MQTT broker. In the shell is executed Python scripts that send messages over MQTT broker to manage the system. This setup is needed in RnD as long as there are tasks that must be done manually by running Python scripts.
I’ll try to change the name of the “custon-docker-compose.service” to “docker-compose.service” to prevent activation of the default docker-compose.service.
some TorizonOS maintenance services will activate the default docker-compose.service to keep docker-compose.yml running.
One such situation is when a systemd service responsible for update Docker image versions. Then the “custom-docker-compose.service” is stopped and started with new Docker image versions.
Well systemctl disable only stops the system from calling this service on boot. It does not prevent other services and process from invoking this service separately. This is also why I suggested using systemctl mask. A masked service will not do anything when called as it becomes a symlink to /dev/null see this for more info: boot - What is the difference between "systemctl mask" and "systemctl disable"? - Ask Ubuntu
Of course though masking this service may break other things in the system since other services expect this service to be running in some shape or form.
The reason I want to have a “custom-docker-compose” service is that in the docker-compose.yml there are MQTT broker + Python containers communicating with each other.
I have defined separate docker network to be able to start additional Python container into shell so that it has access to the MQTT broker. In the shell is executed Python scripts that send messages over MQTT broker to manage the system. This setup is needed in RnD as long as there are tasks that must be done manually by running Python scripts.
I’m not sure I fully understand your system architecture, but it’s obvious you need something more advanced as you said here. Instead of creating a new service why not just modify/overwrite the existing docker-compose.service? That way the service is still running, and any other services/processes that rely on it won’t be possibly broken by it being disabled/masked. Is it not possible to modify the existing service to add the logic you need?
