Container failling to start
seifane opened this issue · 6 comments
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.
Would you try docker run with “--privileged”?
Would you also share your environment details (“docker info”)?
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
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
- 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.
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.
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
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