New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TemporaryDirectoryForBigFiles() can still ignore $TMPDIR #2197
Comments
Yes, Podman did decide to interpret I think this needs to be handled in Podman proper; it is not too onerous to structure the In fact, looking at the code as it is right now, AFAICS the relevant code path uses |
Thanks for the reply! :)
Yes, but (AFAIK)
I'm not sure where https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html:
https://systemd.io/TEMPORARY_DIRECTORIES/:
So I would argue that, at least on modern Linux+systemd systems, the correct (/ standard conformant) behavior would actually be to use
IMO it would ideally be handled in both repos/projects but it should certainly be possible to only change it there. |
Update: I ran into this bug with Podman 4.4.1 on a RHEL 9.2 system. After writing this issue but before submitting it I realized that I only looked a the source-code (old vs. current) and didn't try to reproduce it with a more recent Podman version.
It turns out that Podman 4.7.2 on Fedora 38 might not be affected by this issue (the temporary files end up in- I suspect that the difference comes from not connecting to a Podman service and I'll try to reproduce it with Podman 4.7.2 but IMO this issue applies regardless as the current source code of this repository still contains the problematic code).$TMPDIR
and are prefixedcontainer_images_storage
instead ofstorage
but it's also a very different setup/code-path as I use a systemd service running as root on RHEL while on Fedora I just run Podman as unprivileged user without connecting to a Podman serviceUpdate2: I could reproduce the issue with Podman 4.8.0 (most recent release) on Fedora 38 - the key is indeed the Podman service / using
--remote
.The temporary directory can be very important when writing big files. See #495 for a previous issue on this topic. The situation got improved with #747 but relying on
SystemContext.BigFilesTemporaryDir
doesn't seem to be sufficient assys
isn't always set. I currently have to buildDockerfile
s that produce huge images (unfortunately) on a RHEL 9 system where not only/tmp
but also/var/tmp
is on atmpfs
. This results in such errors:The
TMPDIR
environment variable is set and working (already got me a few build steps further and I can see temporary files prefixed withbuildah
andlibpod_builder
in$TMPDIR
) but the temporary files prefixed withstorage
for committing image layers still end up in/var/tmp
.The relevant source code should be this:
image/internal/tmpdir/tmpdir.go
Lines 10 to 36 in 7721f70
#747 added this part but apparently that still isn't enough:
image/internal/tmpdir/tmpdir.go
Lines 26 to 28 in 7721f70
The documentation of the
os.TempDir()
function is as follows (https://pkg.go.dev/os#TempDir):Apparently the
GetTempPath
function from Windows also considers environment variables:https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks
I therefore propose that we also check for
$TMPDIR
on the non-Windows code path.The following implementation from Podman seems good to me:
https://github.com/containers/podman/blob/b4eb88fca4c48e90067a3558db48eccfa3580261/pkg/util/utils.go#L1042-L1049
So basically something like this (+ updated comments):
IMO that would be the correct behaviour but unfortunately that change could also cause regressions and should probably at least be documented as a breaking change.
Alternatives would be to use a different environment variable (should be less desirable for obvious reasons) or to change the code of Podman to ensure that
sys.BigFilesTemporaryDir
is always set when calling the function (that would work well but it's error prone and the chances of regressions is much higher).What do you think?
The text was updated successfully, but these errors were encountered: