dangling images do not go away with 'podman image prune'
by Matthias Apitz
Hello,
I see a lot of so called dangling images with
$ podman images | more
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/sles15-sp6-v73 latest fcdbe8e4e245 21 hours ago 15.3 GB
<none> <none> e84f83f1637c 4 days ago 20.2 GB
<none> <none> d3921b019185 4 days ago 18.3 GB
...
$ podman images | grep '<none>' | wc -l
34
Yesterday, the number was even 57, then I did 'podman image prune' and
even 'podman image prune -a', the latter with the effect that I have had
to re-build my container 'localhost/sles15-sp6-v73'. But even after the
'-a' the dangling ones did not went away completely.
This causes a serious disk space problem. I run the 'podman images' into
a file, edited it a bit to sum up the used space with bc(1):
$ cat sum-space-with-bc.sh
echo '15300+ 20200+ 18300+ 13700+ 13600+ 13600+ 13300+ 13300+ 7670+ 7650+ 7630+ 7130+ 4330+ 4240+ 4240+ 4240+ 1530+ 568+ 568+ 568+ 568+ 568+ 568+ 568+ 7150+ 7600+ 7510+ 7200+ 6230+ 8840+ 5850+ 5520+ 5520+ 5520+ 5520+ 5520+ 8360+ 130' | bc
$ sh sum-space-with-bc.sh
260406
This number 260 GB matches nearly what I do see in the file system:
# du -sh storage/*
1.0K storage/defaultNetworkBackend
1.3M storage/libpod
266G storage/overlay
^^^^
2.1M storage/overlay-containers
8.3M storage/overlay-images
71M storage/overlay-layers
1.0K storage/storage.lock
0 storage/userns.lock
The podman version is 4.7.2 and the OS is SuSE SLES 15 SP6.
Should I file an issue in https://github.com/containers/podman/issues ?
Thanks
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)
I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
12 months
podman && modify images
by Matthias Apitz
Hello,
We build our image based on the Dockerfile with something like
podman build -t sles15-sp6-v73 sles15-sp6-v73
and run it with
podman run -d -p 2022:22 ....sles15-sp6-v73
Building means that based on the Dockerfile we install the software
which should be come up on container start. This works all fine.
When we now add, install or configure something in addition in
the running container, all this gets lost on killing the container
and restart it again with 'podman run...'
Is it somehow possible to write this modified container to an image and
start this again, and not the image which was build with the Dockerfile?
Thanks
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
12 months
Help running gnome-calculator from a container
by Peter Portante
Hello podman people,
Was wondering if somebody can help me get a simple gnome-calculator
container to work. I'd like to be able to run a container that has
the Gnome-based app in the container but have it display on my
desktop.
So far I am able to create a simple container with the following container file:
FROM registry.fedoraproject.org/fedora
RUN dnf install -y gnome-calculator
CMD ["/usr/bin/gnome-calculator"]
Then once built with:
buildah bud -f ./ContainerFile --tag calc:latest .
I run it using:
podman run -it \
-e WAYLAND_DISPLAY=${WAYLAND_DISPLAY} \
-e XDG_RUNTIME_DIR=/tmp/xdg-runtime-dir \
-e XAUTHORITY=/tmp/xdg-runtime-dir/$(basename ${XAUTHORITY}) \
-v ${XDG_RUNTIME_DIR}:/tmp/xdg-runtime-dir \
--userns=keep-id \
localhost/calc:latest
But nothing is displayed. :(
Thanks for any help or direction you can offer.
-Peter
12 months
PostgreSQL cluster in podman container
by Matthias Apitz
Hello,
We will use podman containers in the future to test the update of our
application server from version 'X' to version 'Y', multiple times and using
always the podman container running version 'X' to test the update
again, i.e. on boot (run) the container has always again the version
'X' to be updated. Part of this is a complete PostgreSQL 15.1 cluster
with the database to be used by the application servers (a complete
Library Management System). The challenging part was the cluster of
around 6 GByte, to not have to load or build it after the launch of the
container. I came up with the idea to create a tar archive of the
complete cluster below /data/postgresql151/ saved this outside and pull
it in while building the podman container. The Dockerfile has for this:
...
# we used a ready to run PostgreSQL cluster from now
#
RUN cp /usr/local/sisis-pap/pgsql-15.1/etc/linux /etc/init.d/postgres
RUN mkdir /data
COPY cluster.tgz /data
RUN tar xPzf /data/cluster.tgz
# Start PostgreSQL server and SSH daemon on container start
#
COPY initSunRise.sh /usr/local/bin/initSunRise.sh
RUN chmod 0755 /usr/local/bin/initSunRise.sh
RUN echo "/etc/init.d/postgres start" >> /usr/local/bin/start.sh
RUN echo "/usr/local/bin/initSunRise.sh" >> /usr/local/bin/start.sh
RUN echo "/usr/sbin/sshd -D" >> /usr/local/bin/start.sh
RUN chmod 0755 /usr/local/bin/start.sh
...
EXPOSE 22 8076 3045
ENTRYPOINT /usr/local/bin/start.sh
STOPSIGNAL SIGQUIT
If we have to change something in the cluster, for example content of
tables, we have to export a fresh copy to the file cluster.tgz again and
build the container again.
This works fine and a start of the container with
podman run -d -p 2022:22 -p .... sles15-sp6-v73
make the system available for SSH in a few seconds with the PostgreSQL server
and all app servers launched and ready to use for the update to 'Y'.
Comments or hints for improvement?
matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)
I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.
1 year
