Is the docker writable layer removed after a restart / reboot / ...?

In case you are not using volumes, I want to understand when files written by a certain docker service (to the container writable layer) become deleted ?

In particular I am intereseted in the following scenarios for a multiple container application:

  1. restarting the specific docker service using balena dashboard
  2. stopping the specific docker service using balena dashboard and then starting it again using balena dashboard.
  3. restarting your multiple container application using balena dashboard.
  4. the specific docker service becomes automatically restarted by balena due to a crash/exit.
  5. rebooting the device that is running your multiple container application using balena dashboard.
  6. Shutdown of the device that is running your multiple container application using balena dashboard and then manually restarting it again.
  7. pushing (deploying) again the multiple container balena application that doesn’t change the specific docker application.

kr
Jan

Hi, what do you mean by rebooting your multiple container application? You can only reboot a device.

Sorry, I meant rebooting the device that is running the multiple container application
and I also meant shutdown the device that is running the multiple container application.

I have updated my initial post to correct this.

Layers are persistent for the life of that container, but if something causes the recreation of the container (service definition changes like envvars, or envvar value changes, etc) then the layers are lost and the FS is recreated from the image. Restarting service or rebooting device without changing anything related to the service will not recreate file system.

I have just created a file for a certain docker container service and then restarted the service via the balena dashboard and the file is gone after the restart.

So this seems to indicate that restarting the service through balena dashboard does recreate the file system.

Hi @janvda.
A persistent volume is the recommended way for storing persistent data. Any files on the container filesystem, may be removed (as a container may be recreated due to a failure, a reboot, a new release and a variety of reasons). Some more info: Multicontainer: how to configure persistent storage and https://www.balena.io/docs/reference/supervisor/docker-compose/

I am well aware of persistent volumes and I am well aware that files written to writable layer of your docker container are lost after deploying a new container version.

I just wanted to understand what happens with any of the files created in the 7 cases above. It is mainly for troubleshooting.

It should be easy to find out how each case behaves by SSH’ing into the device and monitoring the output of balena ps -a while performing the actions you mentioned. Given the data is removed any time the container is removed, if you observe the container ID changing then you can be sure data have been removed.

Thanks for the tip.

Using the tip I have checked this for a multi container application using balenaOS 2.43.0+rev1
Based on this the filesystem becomes only deleted when

  • “restarting” the specific docker service using balena dashboard
  • “restarting the application” using balena dashboard

In the 5 other cases, it doesn’t become deleted.

  • So a stop and manually start of the balena service doesn’t delete the file system while restarting does delete the file system.
  • Also pushing a multi container application will only delete the file system of a specific container, if that specific container effectively became updated.