ONLYOFFICE / Docker-CommunityServer

Collaborative system for managing documents, projects, customer relations and emails in one place
MIT License
497 stars 180 forks source link

run-community-server.sh fails to detect docker in newer linux kernels (cgroups-v2) and fails to start #122

Open caldwell opened 3 years ago

caldwell commented 3 years ago

This line in run-community-server.sh:

if cat /proc/1/cgroup | grep -qE "docker|lxc|kubepods|libpod"; then

Doesn't work any more. On linux 5.10 when I cat this inside docker containers I get:

# cat /proc/1/cgroup
0::/

This is expected behavior, according to the cgroups-v2 documentation:

If legacy cgroup is in use in the system, this file may contain multiple lines, one for each hierarchy. The entry for cgroup v2 is always in the format "0::$PATH"

This results in the DOCKER_ENABLED variable set incorrectly and the server failing to start.

This stackoverflow question mentions the problem but no one has answered yet.

Carazyda commented 3 years ago

Hello @caldwell Sorry, but i can't reproduce your problem. Please describe how you run the docker container?

caldwell commented 3 years ago

I'm running docker-compose up. The relevant part of the log shows this:

+ cat /proc/1/cgroup
+ grep -qE 'docker|lxc|kubepods|libpod'
+ DOCKER_ENABLED=false

That corresponds to this part of the startup script:

if cat /proc/1/cgroup | grep -qE "docker|lxc|kubepods|libpod"; then
        DOCKER_ENABLED=true;
else
    DOCKER_ENABLED=false;
fi

To debug I ran the docker image by hand:

$ docker run -it --rm --entrypoint /bin/bash onlyoffice/communityserver:11.0.0.1458
root@6913a5edf206:/# uname -a
Linux 6913a5edf206 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) x86_64 x86_64 x86_64 GNU/Linux
root@6913a5edf206:/# cat /proc/1/cgroup
0::/
root@6913a5edf206:/# grep cgroup /proc/filesystems
nodev   cgroup
nodev   cgroup2
root@6913a5edf206:/#

Searching for that 0::/ let me to the cgroups-v2 documentation, which my Debian box appears to be using.

Carazyda commented 3 years ago

Sorry, but I still can't reproduce your problem. It seems to be in the host machine. What OS are you using? Have you tried updating to the latest version or using a different OS?

caldwell commented 3 years ago

I'm running Debian "testing". It's probably working for you because you are on an OS with the old cgroups. On my Debian "testing" machine it only has the new stuff:

$ mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)

On an older Ubuntu Bionic machine it has both:

$ mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)

I tracked this down to the Debian version of systemd:

systemd (247.2-2) unstable; urgency=medium

  * Switch to "unified" cgroup hierarchy (i.e. cgroupv2) (Closes: #943981)

 -- Michael Biebl <biebl@debian.org>  Mon, 21 Dec 2020 20:06:49 +0100

The bug referenced is this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981

That version of systemd isn't in Ubuntu 20.04.2 LTS ("Focal"), since the change seems to have happened in Jan, 2020. It looks like Ubuntu 21.04 doesn't have it either—according to this they explicitly turned it off because their snap stuff wasn't working. Though you'll notice in the bug referenced in that email that they're attempting to get unified cgroups in Ubuntu 21.10.

Bevito commented 3 years ago

Hi,

I just wanted to inform you, that I have the same issue with Debian Bullseye (stable). I use OnlyOffice Workpsace Enterprise with docker, and with Debian Bullseye, community server keep restart in loop. The docker logs says "System has not been booted with systemd as init system (PID 1). Can't operate.".

Some users complains that the service was not accessible anymore, so I reinstalled the server with Debian Buster (oldstable) and everything is working. I think there is a problem with cgroup v2 and docker.

I hope someone can find a solution.

caldwell commented 3 years ago

I think the easy solution would be to set the DOCKER_ENABLED environment variable in the Dockerfile and not try to autodetect docker in run-community-server.sh.

mrodriguezmad commented 3 years ago

I have the same problem, community server is restarting in loop. Debian Bullseye (linux kernel 5.10.0) Community Server 11.5.4.1582