Container failling to start

[seifane]

Hello,

I am having issues starting the container. I tried with docker run and the docker-compose.yml provided in the repo but it results in the same error.

Configure instance ...
Restore from ...
Generate default restore config /etc/3cxpbx/setupconfig.xml ...
Created symlink /etc/systemd/system/multi-user.target.wants/3cx-webconfig.service -> /etc/systemd/system/3cx-webconfig.service.

Welcome to Debian GNU/Linux 10 (buster)!

Failed to create /init.scope control group: Read-only file system
Failed to allocate manager object: Read-only file system
[!!!!!!] Failed to allocate manager object.
Exiting PID 1...

It appears cgroup is supposed to be mounted as RO. So I really don't know what this could be due to.
My distro is Arch Linux if that helps.
Let me know if you need some more info to help identify the issue.

[sinegar]

Would you try docker run with “--privileged”?

Would you also share your environment details (“docker info”)?

[seifane]

Running it with --privileged doesn't seem to fix it

docker run --privileged -t --tmpfs /tmp --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 5015:5015 -p 5000:5000 -p 5001:5001 -p 5060:5060 -p 5060:5060/udp -p 5090:5090 -p 5090:5090/udp ghcr.io/izer-xyz/3cx:latest

Configure instance ...
Restore from ...
Generate default restore config /etc/3cxpbx/setupconfig.xml ...
Created symlink /etc/systemd/system/multi-user.target.wants/3cx-webconfig.service -> /etc/systemd/system/3cx-webconfig.service.

Welcome to Debian GNU/Linux 10 (buster)!

Failed to create /init.scope control group: Read-only file system
Failed to allocate manager object: Read-only file system
[!!!!!!] Failed to allocate manager object.
Exiting PID 1...

Here's the output for docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  compose: Docker Compose (Docker Inc., 2.2.3)

Server:
 Containers: 5
  Running: 2
  Paused: 0
  Stopped: 3
 Images: 90
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1407cab509ff0d96baa4f0eb6ff9980270e6e620.m
 runc version: v1.1.0-0-g067aaf85
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.11-arch2-1-vfio
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 31.26GiB
 Name: EternalPain
 ID: 3UBB:3MUD:T7FW:2RCF:XZKD:DNIA:2U4F:2XRM:F3CG:Z5R4:QY4W:XL3T
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[sinegar]

The only difference with my environments, which may cause issue, is the “Cgroup Version: 2” (mines are 1).

• https://serverfault.com/questions/1053187/systemd-fails-to-run-in-a-docker-container-when-using-cgroupv2-cgroupns-priva/1054414#1054414
• Unable to run systemd in docker with ro /sys/fs/cgroup after systemd 248 host upgrade moby/moby#42275

You might want to play with some of the suggestion in the links. For me, I will need to read them in detail and try to spin up an environment with recent host systemd / cgroup v2 - not sure when I will have the time.

[seifane]

Yeah that indeed seems to be the issue. I will try to tinker with it and report my findings here when I have time !
Thanks for the help.

[sinegar]

I couldn’t setup an environment with cgroup v2. But if you have access to the boot parameters of your host this seems to be the easiest solution as it enables hybrid cgroup:

echo 'GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false' > /etc/default/grub.d/cgroup.cfg

update-grub

https://serverfault.com/a/1083451

[sinegar]

I found another workaround for cgroup v2 if using docker cli (not compose):

--cgroupns=host -v /sys/fs/cgroup:/sys/fs/cgroup:rw

However, I am not sure about the side effects of using the host cgroups in rw. But it resolved the issue in the github action with the latest ubuntu image

mviereck/x11docker#349 (comment)