search

rkt / rkt

[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.
Apache License 2.0
8.82k stars 883 forks source link

Bad behavior with /dev/shm as mountpoint #1334

Open titilambert opened 9 years ago

titilambert commented 9 years ago

Hello,

I need to share /dev/shm to my containers and it's doesn't work. I found a workaround using volumes 

...
    "mountPoints": [
            {
                "name": "dev-shm",
                "path": "/dev/shm",
                "readOnly": false
            },
...

When I start the pod (with --volume dev-shm,kind=host,source=/dev/shm), the first thing I do is to umount /dev/shm from the container ...

jonboulle commented 9 years ago

Hmm, you shouldn't need to manually add /dev/shm, it should be provided by default (per the appc spec - https://github.com/appc/spec/blob/master/spec/OS-SPEC.md) - are you definitely not seeing it without that volume?

On Thu, Aug 27, 2015 at 10:09 AM, Thibault Cohen notifications@github.com wrote:

Hello,

I need to share /dev/shm to my containers and it's doesn't work. I found a workaround using volumes

... "mountPoints": [ { "name": "dev-shm", "path": "/dev/shm", "readOnly": false }, ...

When I start the pod (with --volume dev-shm,kind=host,source=/dev/shm), the first thing I do is to umount /dev/shm from the container ...

— Reply to this email directly or view it on GitHub https://github.com/coreos/rkt/issues/1334.

iaguis commented 9 years ago

We talked about this yesterday on IRC.

The default /dev/shm works but what the op wants is to share the host's /dev/shm between several containers using a volume.

The volume is mounted correctly by systemd-nspawn but then systemd in stage1 mounts a fresh /dev/shm on top, masking it. Hence, to see the host's dir (volume) it needs to be unmounted.

steveej commented 9 years ago

This looks like a very hacky way to share memory between containers (and the host). The allocated memory will not be accounted for the container(s) either. Personally, I'm undecided if this is a good idea to say the least.

@titilambert: have you solved the use-case differently by now or are you still planning on sharing /dev/shm between multiple containers? Have you considered using an in-memory database and/or sharing a UNIX domain socket between your containers?