I have been collecting metrics on my BalenaFin multi-container application using Telegraf and Influxdb, and as I was looking through the data, grouping by “container_name”, I noticed that occasionally a new container would be logged for a single data collection period (I log every 15s), then never be seen again. This is leading to a long list of auto-named containers that are not active, or as far as I can tell, anything to do with my application or the supervisor.
Here is a snapshot of some of the container names detected, including 4 versions of my “influxdb” container:
I have 842 different named containers detected since June 26th (~18 days of logging). About 16 of them are different versions of my containers, 1 is the balena supervisor, and the rest appear to be these momentary auto-named containers.
I have retention policies on my data, so old names will eventually get cleared out, and I can try to set up a manual clear-up of these container names from the database, but would like to find out if they should be there in the first place!
What you’ve found is our balena-engine healthcheck. Every 3min or so it starts a small, temporary container, and checks for errors. It’s essentially the hello-world container from all of the Docker examples.
The script that runs the container is here. I see that we aren’t assigning a name to the container as it gets removed immediately with the --rm flag, but that’s why it is generating auto-names in your log.
If this is an problem for your application, we could consider adjusting the script to use a fixed container name and make sure it is cleaned up manually before and after to avoid conflicts.
I’ve opened this GH issue for tracking, feel free to comment over there or submit a PR if it’s a high priority for you!
Thanks @klutchell for getting that change merged into BalenaOS. We’ve started using the latest BalenaFin OS in our testing and appreciating the reduction in container name clutter in our databases.
