Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1513909 - /dev/shm too small
Summary: /dev/shm too small
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Paul Weil
QA Contact: Xiaoli Tian
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-16 09:26 UTC by Aleksandar Kostadinov
Modified: 2017-11-29 08:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-11-28 21:45:24 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Aleksandar Kostadinov 2017-11-16 09:26:10 UTC
Description of problem:
/dev/shm on pods is only 64MB. There is no way to set this value presently. There are upstream open issues and PRs about it. Most interesting I think are:

* - pull to add such support

I think it makes most sense to have /dev/shm default to the pod memory limit. Having it configurable per pod would be an added bonus.

Version-Release number of selected component (if applicable):
openshift v3.
kubernetes v1.6.1+5115d708d7

How reproducible:

Steps to Reproduce:
1. create pod
2. launch chome

Actual results:
chrome crash

Expected results:
chrome executes

Additional info:
This shm size limits the ability of users to execute application tests using Chrome. As well many databases and other software requires large shm.

Comment 1 Seth Jennings 2017-11-16 15:39:00 UTC
Have you tried ?

There is no upstream change for this and no one working on it that I'm aware.

Comment 2 Aleksandar Kostadinov 2017-11-16 16:21:59 UTC
Yes, it is working but size of /dev/shm is dependent on host, not on container memory limits. On the bright side it works.

On the other hand it is an additional configuration that one needs to apply and it can be very frustrating until user understands what the problem is and how to fix. One colleague spend a lot of time on it and then it also took me more time than expected to understand.

e.g. for each pod template defined in jenkins, one has to go to advanced settings and add volume properly. It is not very useful OOB experience for CI use cases.

In any case, from UX point of view, it makes most sense for /dev/shm to depend on pod/container memory limit and avoid an confusion.

P.S. also it seems one can't rely on applications to report this problem meaningfully and debugging inside a container is something not everybody is up to

Comment 3 Aleksandar Kostadinov 2017-11-17 22:35:57 UTC
One use case raised upstream where size is required [1]. Oracle require large sizes.


Comment 4 Seth Jennings 2017-11-28 21:45:24 UTC
The upstream PR was closed due to inactivity.  We would be starting from scratch pushing this upstream and there doesn't seem to be any urgent desire for this in light of the workaround.

I am closing this as this functionality can be achieved; you just have know what you are doing (i.e. create a tmpfs emptydir and mount at /dev/shm).

What is desired from this bug is just implying the /dev/shm size from the memory limit on the pod.

However, in that case, you _still_ have to know what your are doing.  You must know that implication and set a memory limit on your pod.  That is a non-obvious connection and could make it even more confusing.  It could also break compatibility with pods that currently have an memory limit <64Mi as suddenly /dev/shm would be smaller.

Comment 5 Aleksandar Kostadinov 2017-11-29 08:31:23 UTC
If you have a pod with mem limit <64Mi, then they shouldn't be allowed to use more than that limit anyway.

And I'm not sure what you mean by "urgent desire" here. A lot of people reported issue with this. If you don't set limit presently, /dev/shm will be too small. Without a memory limit on the pod, /dev/shm makes sense to behave as presently when the mount point is overridden (/dev/shm depends on host mem).

This is a UX issue. It seems non-critical for achieving some ends. But things build up. e.g. to run a chrome or some db pod one has to create a template. Will not be possible to just use `oc run ...`. 

My main concern is dev experience. Chrome is the most popular browser atm it seems and requires a bigger /dev/shm. Many projects are relying on chrome for testing. such projects will not be so easily testable inside OpenShift as I would  like. It is also hard to debug the reason it fails to run. My desire is to have a smooth UX as much as possible, that's why I filed this bug.

Note You need to log in before you can comment on or make changes to this bug.