Docker-compose service `inactive` after combined lockbox update

Technical Support
, , , ,
1

Dear community,

When applying Torizon OS (6.4.0) lockboxes for combined (docker-compose + OS) offline updates, the docker-compose service is reported as inactive after the reboot from a successful update (aktualizr).

 root@colibri-imx8x-00000000:/var/rootdirs/home/torizon# systemctl status docker-compose
* docker-compose.service - Docker Compose service with docker compose
     Loaded: loaded (/usr/lib/systemd/system/docker-compose.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Fri 2023-11-24 07:45:49 UTC; 34min ago
             `- ConditionPathExists=!/var/sota/storage/docker-compose/docker-compose.yml.tmp was not met

Nov 24 07:45:45 colibri-imx8x-00000000 systemd[1]: Docker Compose service with docker compose was skipped because of a failed condition check (ConditionPathExists=!/var/sota/storage/do>
Nov 24 07:45:49 colibri-imx8x-00000000 systemd[1]: Docker Compose service with docker compose was skipped because of a failed condition check (ConditionPathExists=!/var/sota/storage/do

It seems like it expects to have no tmp file from the update (/var/sota/storage/docker-compose/docker-compose.yml.tmp). But at the time when checking the docker-compose status, this file doesn’t exist (anymore).

When rebooting the system again (manually), everything seems ok and the docker-compose service comes up fine and is active.

Is this behavior something to worry about (e.g. because of a misconfiguration on our side) or can it be ignored (I don’t know the side effect of the docker-service in an inactive state)?

Thanks for your help.

Regards,

Lukas

2

Greetings @lzaugg_parametric,

This behavior is by design: docker-compose: do not start service upon a synchronous update · toradex/meta-toradex-torizon@bf77397 · GitHub

During a synchronous update the “new” docker-compose file is written to this /var/sota/storage/docker-compose/docker-compose.yml.tmp file. This will eventually overwrite the proper /var/sota/storage/docker-compose/docker-compose.yml file only after the rest of the update is confirmed good. But this only happens after reboot since we need to confirm the OS portion of the update was successful. Because of this we don’t want docker-compose.service to start any containers since it would start the old containers since at boot-time /var/sota/storage/docker-compose/docker-compose.yml still contains the old contents, as the switch with the temp file hasn’t happened just yet.

In summary, this is fine and intended. As long as your update was successful that’s all that matters.

Best Regards,
Jeremias

3

Thanks @jeremias.tx ,
Great and precise answer, as always :).

Really appreciate the customer support from Toradex.

4

Glad I was able to help clarify!