I’ve created several Fedora CoreOS Virtual Machines for one service like Dokuwiki on each. In these machines an unprivileged user runs these services using podman and systemd units that run “lingered”.
As times go by, my node_exporter (prometheus, also running as systemd unit but with different user) made my grafana alerts trigger telling me that the folder /sysroot/ostree/deploy/fedora-coreos/var/ is running out of space (after short research it’s the tmp folder in there that grows without limit). When i open /sysroot/ostree/deploy/fedora-coreos/var/tmp i see 4 folders owned by root (with almost no content) and lots, lots of folders owned by the unpriviliged user dokuwiki that runs the dokuwiki container as systemd unit. Opening one of these folders show me that there are files just named by number 1, 2, 3 and so on, as the network traffic showed up te be the same like a docker pull i tried to convert these 1 2 3 files to something.tar.gz and opened it using 7zip showing me for an example that it’s content is a bitnami/dokuwiki container, what I expected. So each time the systemd unit starts it tries to pull the latest images, which is ok and works as intended. But at first, why these temporarily downloads remain at /sysroot/ostree/deploy/fedora-coreos/var/tmp and why these directories does not get cleaned up after reboot, onece a day (another systemd per default ought to run named 'systemd-tmpflies-clean.service / .timer) both are enabled and executed but did not clean up anything. So what do I miss here? I am pretty new to fcos but as far i know the /sysroot/ostree/deploy/fedora-coreos/var/ path is, from a ostree prerspective, ment to contain app data that changes and the tmp folder there ought to be deleted automatically. I’ve read that I might be able to set up the tmp file path for podman by using an environment variable but I just use the fcos image in a pretty default way, its version is ‘fedora-coreos-36.20220605.3.0-live.x86_64.iso’ and the problem remains even after zinactl service updated it to latest version.
I have no clue what the problem is and journalctl and /var/logs do not tell me any amazing story. So your help is very much appreciated
Do you have an example butane config of your setup or at least the systemd units that you are running (with linger) that are starting the containers and leaving behind files?
Sorry Dusty for the late response, I was unable to post due to illness.
Above is the ingnition.yml I use in combination with the windows version of buthane.
Here the content of the bat file I use to create the installer iso file:
To temporarily clean up the disk space i used the folowing statement as root:
(Is it safe to use it? → it will delete all folders in there that are older than one day and containing storage in their name)
/var/tmp is not cleaned-up automatically on reboot. So you’ll have to figure out which container or program is writing to it and use /tmp or something else instead.
Do you know why podman (and maebye docker aswell), which is preinstalled and preconfigured by FCOS, stores stuff in /sysroot/ostree/deploy/fedora-coreos/var/tmp instead of /tmp?
And shouldn’t the /sysroot/ostree/deploy/fedora-coreos/var/tmp path be cleaned automatically too, because it is named like a temporary content folder?
The program writing to /var/tmp ought to be podman because the folder is being filled up by downloaded container images, as written in the first entry of this discussion.
/sysroot/ostree/deploy/fedora-coreos/var/tmp is /var/tmp.
I don’t have anything in /var/tmp on my FCOS server so you need to find in your setup what’s doing that. Maybe it’s podman storing the top layer changes from the container on the disk there?