Always mount a /run tmpfs in the container

[alexlarsson]

All modern distros set up /run to be a tmpfs, see for instance:
https://wiki.debian.org/ReleaseGoals/RunDirectory

Its a very useful place to store pid-files, sockets and other things
that only live at runtime and that should not be stored in the image.

This is also useful when running systemd inside a container, as it
will try to mount /run if not already mounted, which will fail for
non-privileged container.

Docker-DCO-1.1-Signed-off-by: Alexander Larsson alexl@redhat.com (github: alexlarsson)

[rjnagal]

Do we need to verify if /run is already setup and non-empty in the provided rootfs before mounting a tmpfs over it? We might be hiding away an existing tmpfs setup in some cases.

[alexlarsson]

@rjnagal How could there be another tmpfs already set up? We've just mounted the root fs ourselves.

Now, its possible that the image had some files in /run, which we may hide. However, that is quite unlikely as any images that use standard distro packages will see the same behaviour on a normal boot.

[rjnagal]

This shouldn't be a problem for standard distros. It can only break custom
images. There are use-cases that want to /var/run/docker.sock to be
visible. It might get hidden.

On Wed, May 7, 2014 at 11:18 PM, Alexander Larsson <notifications@github.com

wrote:

@rjnagal https://github.com/rjnagal How could there be another tmpfs
already set up? We've just mounted the root fs ourselves.

Now, its possible that the image had some files in /run, which we may
hide. However, that is quite unlikely as any images that use standard
distro packages will see the same behaviour on a normal boot.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5655#issuecomment-42516776
.

[alexlarsson]

@rjnagal When would you want that? I can see using that as a volume, and yes, that would break with this as the /run would cover the files we create to bind-mount on. Thats already broken for /dev for the same reasons:

# docker run -t -i -v /dev/log:/dev/log fedora bash
2014/05/08 19:40:54 setup mount namespace bind mounts mounting /dev/log into /var/lib/docker/devicemapper/mnt/45c3e6df73f0a2988644f15f7318c005bed52c00ea1cdc837f4840e984747f2a/rootfs/dev/log no such file or directory

[rjnagal]

@alexlarsson that's the thing I am seeing. I mistook 'system mounts in init
being the last mounts' as a feature. Mounting /run would be fine as long as
we don't hide any volumes.

On Thu, May 8, 2014 at 10:41 AM, Alexander Larsson <notifications@github.com

wrote:

@rjnagal https://github.com/rjnagal When would you want that? I can see
using that as a volume, and yes, that would break with this as the /run
would cover the files we create to bind-mount on. Thats already broken for
/dev for the same reasons:

docker run -t -i -v /dev/log:/dev/log fedora bash

2014/05/08 19:40:54 setup mount namespace bind mounts mounting /dev/log into /var/lib/docker/devicemapper/mnt/45c3e6df73f0a2988644f15f7318c005bed52c00ea1cdc837f4840e984747f2a/rootfs/dev/log no such file or directory

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5655#issuecomment-42581028
.

[alexlarsson]

This last change allows volumes in /run to work in the native driver. However, i'm not sure how to do this in lxc...

[alexlarsson]

New rebase that dropped the /dev/log fix as that is already in master now.

[crosbymichael]

ping @creack do you think that doing this is ok?

[creack]

Yes. Will try today.

[crosbymichael]

I think this makes sense and is best in the long run.

LGTM

ping @rjnagal @vmarmol

[creack]

LGTM

[rjnagal]

LGTM

I don't have pull permissions, but it looks fine to me.

On Mon, May 12, 2014 at 3:12 PM, Guillaume J. Charmes <
notifications@github.com> wrote:

LGTM

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5655#issuecomment-42895142
.

[vmarmol]

LGTM

lmctfy has started to do this as well so I'm definitely already in the /run as tmpfs camp :)

[unclejack]

LGTM