Question How to remove unused image

Currently reading
Question How to remove unused image

914
313
NAS
DS418play, DS213j, DSM 7.0.1-14401
Portainer shows an unused image... python:3.8-slim. I'm guessing that it was once installed by a container.

However... All my current containers are running and this image is "unused" (there is no other python:3.8-slim image, active or otherwise).

Removal fails, including forced removal.



Since all my containers are running, and this image is "unused" (and my only unused image), how can it have dependent child images, and how would I find out which those are?

Any thoughts here? Seems like it should be an innocent orphan.
 
This is because you have containers running which use an image that bases on the image (actualy it's image layers) you try to delete.

An "image" is actualy a pointer to a tag, which itself points to a sha256 checksum of meta data that contains information which image layers are required in which order to make up the image. Additionaly the sha256 cheksum is created for each image layer. If an image layer already exists (=identified by sha256 checksum) it is reused and not downloaded again. So even if you manage to remove the tag in a way that it does not appear in "docker image ls", the image layers will still be present, as they are used by child images. It is like removing a bookmark - but not deleting the link target. Does that make sense?

Docker storage is so efficient, because the image layers from base images will be reused amongst child images AND containers will use them as well: all image layers of the image are mounted as read-only filesystem in a virtual filesystem and a copy on write layer is added on top (this is the per container individual part).
 
Last edited:
914
313
NAS
DS418play, DS213j, DSM 7.0.1-14401
Thank you.

I used this command...
Code:
docker inspect --format='{{.Id}} {{.Parent}}' $(docker images --filter since=9d84edf35a0a -q)
It identified 6 other active images (each connected to a container). So I'm confused why Portainer would call this image "unused" if other containers require it.

A related question... If the other running containers need this "unused" image, I presume they could update it ... or do I do that? If so, how would the updated image displace the older version of itself?

Sorry for what are probably "dumb questions"... the terminology isn't clear to me.
 
It identified 6 other active images (each connected to a container). So I'm confused why Portainer would call this image "unused" if other containers require it.
I assume it just checks if a container exists that uses the sha256 checksum of the image. From that perspective it is correct to indiciate the "image" is unused.

A related question... If the other running containers need this "unused" image, I presume they could update it ... or do I do that? If so, how would the updated image displace the older version of itself?
Well this one is kind of tricky to explain.

First things first: this is a task for the image maintainer, not for the end user.

Some tags are mutable (like "latest" or specific major.minor versions) and some are immutable (like exact version). Docker only pulls image:tags combinations, if they do not exist in the local image cache. Now the problem with mutable tags is, if an older version (any previous sha256 checksum version of the image) already exists in the local image cache, it won't be updated automaticly. Fun fact: a container will always be created based on a specific sha256 checksum version of an image, thus updating the image of a mutable tag won't lead to an updated image for that container - it will still be "bound" to the old image.

When images are build and the base image is present in the local image cache, it will not be updated (like described earlier). In order to build an image with the newest version of the base image, it needs to be explicitly pulled beforehands.

As soon as you pull/build a later image for an already existing mutable tag, the new image (identified by its sha256 checksum) will claim the tag and the old will be listed with the tag <none>.
 
Last edited:
Sorry for what are probably "dumb questions"... the terminology isn't clear to me.
The offical terminology is ambigous itself:

What is an image?
Is it just the repo(sitory) (e.g. ubuntu) or repo:tag (e.g. ubuntu:18.04) or even [email protected] (aka sha256 checksum)?

A specific tag points to a [email protected], for an immutable tag the repo:tag is equivalent (as it will always point to the same [email protected]), but for a mutable tag the exact [email protected] is obfuscated and will eventualy updated to another [email protected] in the repository (though, it will remain the same in the local image cache, until it gets update to a more recent [email protected])

The problem is, that the terminology changes in different contexts:
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
here: IMAGE == repo:tag or [email protected] (this is consistent with how it is used in docker-compose.yml files)

But then we have functions like docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
here: *_IMAGE == repo

And again a different terminology for the same thing in docker pull [OPTIONS] NAME[:TAG|@DIGEST]
here: NAME == repo

And then we have the terminology in an image registry like dockerhub:
A repo is either user/repo or just repo for "offical images" from docker's library.
But then again we have a filter for "images"... :)

Yes, its messed up. Honestly, I am not surprised that people are unclear on the terminology. When someone writes or says image, I am quite sure that different people will understand different things...
 
Last edited:
914
313
NAS
DS418play, DS213j, DSM 7.0.1-14401
Thanks for all that. While I still need to digest it, what I see is that I should leave that "unused" image alone, and plug on...

Earlier today I used a command to clean up "hanging-images" only to realize that took out the previous "mutable" images that were marked "unused" (except for the one I was hoping to delete).

Fortunately no damage :D
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Similar threads

Top