Update causes error.

[fritterhoff]

After the new update I get the following error:
ERROR: for dockerapi-mailcow Cannot start service dockerapi-mailcow: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"process_linux.go:367: setting cgroup config for procHooks process caused \\\"failed to write 1 to memory.oom_control: write /sys/fs/cgroup/memory/docker/eff49d3cd69560001f3bc50f38bc4b489381454d4b835f2de159a794006bb9ac/memory.oom_control: permission denied\\\"\"": unknown ERROR: Encountered errors while bringing up the project.
Removing and reinstalling images and containers does not help.

[andryyy]

Remove oom_kill_disable: true from all services that use this parameters in docker-compose.yml.

But this shouldn't happen anyway...

Please post infos about your system. Is it a LXC container?

Are you using a non-root user?

[fritterhoff]

No at the Moment I'm using a root User.

oom_kill_disable: true is enabled in some Services... I will disable it and try again. (In the current master File it is also enabled...)

Details about system: Simple good old Intel NUC, SSD and a static ip. Debian 9 installed ...

[andryyy]

Yes, it is enabled because it should work and is not something bad or uncommon...

[PeterHagen]

With a clean install (new machine and following the mailcow-dockerized-docs/install/ instructions), I also run into problems. Removing the oom_kill_disable line from the docker-compose file works.

[Knight1]

What reports docker info, what Distro is it, kernel version?
From what I can tell either the kernel is not build with it or the Intel NUC CPU does not support it.

[PMK]

Here as well with a new fresh install on a fresh installed Ubuntu 18 LTS virtual machine.

$ sudo docker-compose up -d
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.dockerapi-mailcow: 'oom_kill_disable'
Unsupported config option for services.watchdog-mailcow: 'oom_kill_disable'

Docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-36-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.853GiB
Name: xxx
ID: MEC5:L3T5:YJKM:PB2X:4V5Q:Z2SC:YOKT:6WRQ:UA2L:GX3W:RPJ7:2NU5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

$ uname -a
Linux 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[PMK]

@andryyy Which version of Docker do you have?

I think somewhere in this history the flag is removed in favor of oom_score. Note that the link is a design proposal
See also this old issue about this flag: moby/moby#14440

My assumptions are not true:
https://docs.docker.com/config/containers/resource_constraints/#understand-the-risks-of-running-out-of-memory
https://docs.docker.com/compose/compose-file/compose-file-v2/#cpu-and-other-resources

So I think for these containers the memory property needs to be defined.

More info:
https://stackoverflow.com/a/48618727

[PeterHagen]

I'm not sure if anyone still has this issue, but it seems that Ubuntu 18.04 ships with docker-compose 1.17.1, while oom_kill_disable is a 1.18 feature. I used this page to update to 1.22. And then it seems to work

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[derspotter]

I am still encountering this problem. Fresh Debian 10 and docker install. Mailcow is the first container.

`ERROR: for mailcowdockerized_dockerapi-mailcow_1 Cannot start service dockerapi-mailcow: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused "process_linux.go:415: setting cgroup config for procHooks process caused \"failed to write \\\"1\\\" to \\\"/sys/fs/cgroup/memory/docker/a3957e68f39cc0ada08c7f61215a99b634a38c2f9a09c555f11bc7dcc4af572a/memory.oom_control\\\": write /sys/fs/cgroup/memory/docker/a3957e68f39cc0ada08c7f61215a99b634a38c2f9a09c555f11bc7dcc4af572a/memory.oom_control: permission denied\""": unknown

ERROR: for dockerapi-mailcow Cannot start service dockerapi-mailcow: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused "process_linux.go:415: setting cgroup config for procHooks process caused \"failed to write \\\"1\\\" to \\\"/sys/fs/cgroup/memory/docker/a3957e68f39cc0ada08c7f61215a99b634a38c2f9a09c555f11bc7dcc4af572a/memory.oom_control\\\": write /sys/fs/cgroup/memory/docker/a3957e68f39cc0ada08c7f61215a99b634a38c2f9a09c555f11bc7dcc4af572a/memory.oom_control: permission denied\""": unknown
ERROR: Encountered errors while bringing up the project.`

[andryyy]

Do not use container based virtualization for your host system.

[derspotter]

Why?

[kenji21]

similar issue with net.core.somaxconn sysctl key:

ERROR: for redis-mailcow  Cannot start service redis-mailcow: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: write sysctl key net.core.somaxconn: open /proc/sys/net/core/somaxconn: no such file or directory: unknown
ERROR: Encountered errors while bringing up the project.

Running mailcow in a proxmox container, commented out systcls lines in docker-composer.yml fixed the starting of mailcow