I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Based on the documentation, yes, Torizon OS does automatically prune unreferenced images after successful application updates(1). The system implements a comprehensive cleanup process to manage storage space.
Application Update Process and Image Cleanup
During application container updates, Torizon OS performs the following sequence(1):
Source the new container images - runs docker-compose pull --no-parallel on the new docker-compose.yml(1)
Stop old containers - runs docker-compose -p torizon down on the old docker-compose.yml(1)
Start new containers - runs docker-compose -p torizon up --detach --remove-orphans on the new docker-compose.yml(1)
Clean up unused resources - executes docker system prune -a --force to clean up any unused containers, networks, and images from the device(1)
Automatic Image Pruning
The final step in the update process specifically addresses your concern about unreferenced images. The system runs docker system prune -a --force which removes(1):
Unused containers
Unused networks
Unused images (including those no longer referenced by the new docker-compose.yml)
This ensures that images from previous application versions that are no longer needed are automatically cleaned up, preventing storage bloat on your device.
Manual Pruning
You can also manually trigger this cleanup process at any time using the docker system prune command(2):
# docker system prune
This will remove all stopped containers, unused networks, dangling images, and dangling build cache(2).
The automatic pruning during updates ensures your system maintains optimal storage usage without manual intervention.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
In typical cases this should removed any unused containers and images. However, this affects even images referenced by the current compose file if the containers were short-lived enough and exit before the cleanup command is executed, as the commit I referenced stated. The comment was in reference to improving this specific behavior.
Do you have short-lived containers in your setup that result in the corresponding images being removed? Or did you actually observe any other strange behavior that led to your question here?
Yes, I have two short-lived containers in my setup and I saw something strange in some rare circumstances. For this reason I started a wide-spectrum investigation.
Both of the containers are used to copy files from the container itself to the host and then they close:
the first one copies a lot of files (images, configurations, …) and so this take a while
the second one copies the cortex-m firmware so that uboot can load it at the next boot
I know that both of these needs should be handled with “subsystems” and not containers. And, maybe, this kind of scenarios are the reason why Toradex decided to implement subsystems.
But subsystems didn’t exist yet when we setup this specific couple of containers and I prefer not to change them now (maybe in future release of my application).
I’m not saying that the prune is the reason for the issue I see sometimes. Now I understand better and I can go on with my investigation.
