I’m experimenting with Torizon on the Colibri iMX6ULL.
- take vanilla Torizon
- '> docker run -rm -d --restart always /`
- Turn off, remove power, leave for a day
- plug in, turn on
To my surprise and delight the container was started and run just fine. I am curious to know the mechanism by which it persists? Where can I find details of how this works?
The key is the
--restart-always flag. This causes the container to attempt to restart itself no matter the exit condition. The only way to circumvent this would be an explicit
docker stop on that particular container.
For more info on the various restart policies with Docker containers please consult the Docker documentation here: Docker run reference | Docker Documentation
Thanks @jeremias.tx ,
I understand the docker flag (all the docker flags!). My question is where on the board is that information persisting? When the board is powered off and rebooted, I expected it to boot into the OS I flashed, which is vanilla torizoncore with no images installed. When I ran docker with that
--restart always flag I must have changed something about how boot occurs. I’m wondering how that works - has the flash memory been changed by the docker call?. Why doesn’t it boot to the flashed os (vanilla torizoncore with no images)
Could you explain your test in more details?
Which docker container image you have set to a restart always policy?
When you executed the
docker run rm -d --restart always **name of your container image**, you’ve told docker to execute that given docker image (which you may have previously added to the module or it pulled from docker hub…?) always.
And as the docker engine daemon is programmed to start from boot in our TorizonCore, as soon as Docker starts, it will also start that container you’ve set.
docker run --restart always causes that same image to be run on boot, there must be some change to some config file somewhere so the computer remembers that detail between boots. On a computer with a hard-drive I expect some config file somewhere in the filesystem is updated so that when docker restarts on next boot it knows to run that image.
- where is this file?
- How does it persist between boots on a board with only flash and ram (i.e. no hard-drive)?
I think your doubts are more related to how an embedded system is architected and how docker operates.
In an embedded system with flash memory, the flash memory is the “hard-drive”, where the system will store its data, information, programs, etc.
The restart policies from docker are managed by it and stored in flash memory through the docker-engine environment.
@andrecurvello.tx Thankyou, that was the answer I needed
If TorizonCore treats flash like a HDD, this raises the issue of how long torizoncore can run before the flash wears out. Is TorizonCore doing regular writes (log files, etc)? or are those features of normal linux removed? Can I expect the older Toradex Linux versions to write to flash more or less often? Are there any RAM-only (i.e. don’t write to flash during operation" distros that toradex build?
Our default images are designed for optimal usage of the module resources, including flash.
Of course, there are changes to be made on flash, but the wear-out is likely to occur if that is too frequent, too intense.
That said, even system logs are not set to be persistent by default.
There are some strategies to compensate that, for example, to mount a portion of RAM as a directory of the filesystem, and persist to flash only what is necessary, like configuration data, settings, etc.
But the user can change the system properties at his own risk.
I invite you to have a look at this blog post: https://www.toradex.com/blog/what-you-should-know-about-flash-storage