Skip to content
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.

/tmp directory on ACI being built is unusable #274

Open
dimas opened this issue Nov 29, 2016 · 6 comments
Open

/tmp directory on ACI being built is unusable #274

dimas opened this issue Nov 29, 2016 · 6 comments

Comments

@dimas
Copy link

dimas commented Nov 29, 2016

Neither "acbuild copy" nor commands started with "acbuild run" cannot make any changes on /tmp

$ acbuild run -- touch /tmp/xxx
Running: [touch /tmp/xxx]
$ acbuild run -- ls -l /tmp
Running: [ls -l /tmp]
total 0

To be honest I do not know much on how containers work so maybe that whole tempfs thing lives only for the duration of the command in which case it is an expected behaviour. This theory is supported by

$ acbuild run -- bash -c 'touch /tmp/xxx; ls -l /tmp'
Running: [bash -c touch /tmp/xxx; ls -l /tmp]
total 0
-rw-r--r-- 1 root root 0 Nov 29 09:37 xxx

But maybe it makes sense to put this in docs / FAQ too then? Because /tmp is a typical choice of downloading something before installing it so can save people some time
(I searched first - https://github.com/containers/build/search?utf8=%E2%9C%93&q=tmp)

@J-Swift
Copy link

J-Swift commented Dec 2, 2016

This bit me too, I had to resort to either doing a tmpdir on the host, or manually creating a pseudo-tmpdir in the container which I then clean up afterwards. It had me really confused for a while before I figured out what was going on.

@cgonyeo
Copy link
Member

cgonyeo commented Jan 3, 2017

Right now /tmp in the container is an actual tmpfs created by systemd-nspawn. I think in the not too distant future I'm going to write a runc engine and make that the default, which should hopefully change this behavior.

@sanmai-NL
Copy link
Contributor

Maybe I do not get what you're doing, but it seems proper to me to not include /tmp/ in images. I don't understand what @dgonyeo means where he wrote ‘that the default’ and ‘this behavior’. /tmp being a tmpfs is the current and right situation, not?

@cgonyeo
Copy link
Member

cgonyeo commented Jan 17, 2017

@sanmai-NL /tmp being a tmpfs is only true if a tmpfs is mounted at /tmp. The systemd-nspawn engine (the default) does mount a tmpfs there (or at least deletes the files afterwards, I haven't checked). The chroot engine (which can be enabled with a flag) does not mount a tmpfs there. Thus if users are expecting to be able to put files in /tmp and have them be available inside a run command, the chroot engine must be used.

When I write a runc engine (and I intend for it to be the default eventually) I wasn't planning on mounting a tmpfs unless runc does this already.

@sanmai-NL
Copy link
Contributor

sanmai-NL commented Jul 10, 2017

@dgonyeo: Just encountered this issue, again. Seems like it is still very confusing!
Where would be the appropriate place to document this?

@cgonyeo
Copy link
Member

cgonyeo commented Jul 10, 2017

This should probably be mentioned under the systemd-nspawn section of https://github.com/containers/build/blob/master/Documentation/subcommands/run.md

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants