Docker Community Forums

Share and learn in the Docker community.

Docker for Mac - how to set host settings? sysctl. etc

How does one configure the host with things like:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

or adding vm.overcommit_memory = 1 to /etc/sysctl.conf

Has this question been answered anywhere else? It’s a real problem, not sure why it’s not getting any response.

We’re trying to figure out how the app should best handle this, and if there’s a reasonable default sysctl.conf setup that’ll work for most uses. Can you detail what images you want to run that require these settings to work?

Hi Michael, thanks for responding, but you have me really confused since this feature was already added in the most recent beta (15).

@marclennox yes! I’m just trying to figure out if we can update the defaults so that most users won’t have to modify these settings.

OK, now I understand your response! My apologies.

So for my own use case, I’ve noticed that Rails 5 (in development) uses a file watcher for reloading development files when they are changed. The file watcher seems to require a very large number of inotify watchers, so to avoid problems I need to add the following:


This is perhaps not the best approach, but it solves the problem I was having.

The original question was due to a default redis container:

REDIS | 1:M 13 Jun 03:52:21.677 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

REDIS | 1:M 13 Jun 03:52:21.678 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

REDIS | 1:M 13 Jun 03:52:21.678 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

Also having the same issue with the default redis image. I’ve been trying to figure out how to ssh to the xhyve virtualmachine on OSX but it doesn’t look like ‘docker for mac’ installed the command line tool to access it. Does anyone know how I can access the Alpine Linux running on the VM so these system settings can be tuned?

Because I was having a similar issue I thought I’d put this here for posterity’s sake.

To ‘login’ (attach to a screen session) in docker for mac you do,

screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

login with ‘root’ no password.

set whatever sysctl setting you need to modify. I had to set max_user_watches for inotify.

fs.inotify.max_user_watches = 524288


thanks ,it really helps me

Is there an official way of doing this yet? The first similar post I found on StackOverflow starts telling people to run containers with --privileged to gain access to /etc/ and /sys/ - which seems like a bad idea.

If the screen command is a viable option for logging in and tuning the VM perhaps this can be built into the Docker for Mac GUI so that it becomes an official feature?

Thank you for that. As of December 2019, one has to use a different tty file, which can be found inside of ~/Library/Containers/com.docker.docker/Data/vms/0/.

Now to hunt for a way to make things persistent… :confused:

FWIW, my use case is that I want to be able to use dmesg from containers, but it first requires unrestricting it with sysctl kernel.dmesg_restrict=0 in the host.

By the way, I’ve spent the best part of an hour trying to find how to do this and combing through the history of why docker-machine ssh no longer works. It’d be great if the Docker for Mac documentation mentioned the possibility of connecting to the tty of hyperkit - and it’d be even better if there was some hint about how to permanently customize the host.