18.0.0.1880 container constantly restarts

[MrMontesa]

Hey there & thanks for providing this image.
I'm trying to setup 3CX in my docker setup using the latest tag, but the container constantly restarts. Using the older container works. Here are some details about my setup.
Host OS:

root@docker:~# uname -a
Linux docker 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux
root@docker:~# cat /etc/debian_version
11.0
root@docker:~# docker --version
Docker version 20.10.8, build 3967b7d

setup 3CX container like this:

root@docker:~# docker run -d \
    --name=3CX \
    --restart=unless-stopped \
    -v 3cx_backup:/mnt/backup \
    -v 3cx_recordings:/mnt/recordings \
    -v 3cx_log:/var/log \
    -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
    --security-opt apparmor=unconfined \
    --cap-add SYS_ADMIN \
    --cap-add NET_ADMIN \
     --network DockerLab \
     --ip 192.168.25.23 \
     --hostname phone \
     farfui/3cx:18.0.0.1880

After a few minutes, docker still gives me:

root@docker:~# docker exec -ti 3CX /bin/bash
Error response from daemon: Container 07aa350285ab4a0c94a6adb002ec51861031ea3a17dde8567b83bce4d4205cd8 is restarting, wait until the container is running

checking restartCount increased to 25 in the meantime, which means the container is constantly restarting. It never reaches a state where network is activated and the IP is given.

Do you have an idea how to troubleshoot?
Thanks much!

PS: I'm also testing the older release (16.0.6.655) which starts but errors out with the "Failed to connect to bus: No such file or directory" message.

[Kusig]

Same here, restarts constant.
docker ps -a give:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5f96967437c2 farfui/3cx:18.0.0.1880 "/lib/systemd/systemd" 4 minutes ago Exited (255) 3 minutes ago 3cx

Any idea how this could be further debugged? As the container doesn't come up, there is no chance to go inside the container to get further problem indications

[ekondayan]

You can run docker container logs <3cx_container_name> and see if it has recorded the error.

Meanwhile I've updated the container to version 18.0.2.314.

[ekondayan]

I've updated the container to the latest 3CX version 18.0.2.314. Please try farfui/3cx:18.0.2.314.
It is running without an issues under PhotonOS 3.

If it keeps on restarting, maybe the issue is in your host OS. Try to dig into the logs docker container logs <3cx_container_name>

[Kusig]

Unfortunately no luck as well with the new version. There are no logs reported at all. The only sign of dead I found until now is the exit code 255.

BTW: It works without problems with older 16 image.

Host OS is a fresh Ubuntu 20.04.3

[robvdl]

Yep same here, the container constantly exits with code 255. What's the last known working version so I can install?

[robvdl]

Hi @MrMontesa I also got the error connecting to bus issue with v16 which is described here:

https://askubuntu.com/questions/1190804/timedatectl-failed-to-create-bus-connection-no-such-file-or-directory

Basically it seems you need to add the following mount:

/run/dbus/system_bus_socket:/run/dbus/system_bus_socket:ro

But even then it fails on the final install command so I have yet to get this installed at all. Avoiding repeating myself, I posted about that here already:

mop1987/3cx-Docker#3

Edit: I even tried version 16.0.8.9 (the last of the 16.x series) and same problem. I've had to add -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket:ro that gets it past the setup timezone command. But then as soon as you run the next command, same issue as I discribed in the link above. It seems to de-register and stop all the services and nothing is running on port 5015.

The restart issue and returning code 255 that is definitely an issue with the 18.x series.

[ekondayan]

I've been running v18.0.2.314 for a week now under PhotonOS 3 and docker 19.03 I suppose that the problem lies in the AppArmor/SELinux.

The container is using systemd to run the services. If the container exits with an error code, maybe something is preventing systemd from running. You can try to run the container with --security-opt apparmor=unconfined.

[ekondayan]

I found this article: https://blog.mwpreston.net/2021/09/23/changing-docker-cgroups-from-cgroupsfs-to-systemd/
Could you try changing docker cgroups from cgroupsfs to systemd.

[robvdl]

Cool, I'll give that a try.

[robvdl]

Hi, so I've followed the guide to change docker cgroups to systemd and used --security-opts apparmor=unconfirmed for the docker run command.

My host OS is Debian 11, and the parent interface is called enp4s0 rather than eth0. Here is my command I used to create the macvlan network:

docker network create \
    -d macvlan \
    --subnet 192.168.1.0/24 \
    --gateway 192.168.1.1 \
    -o parent=enp4s0 mv_eth0

I had a look at the syslog and this is what I get, it's looping still restarting with code 255. What would be going on with the network device

Jan  6 14:19:30 aurora systemd[1]: Started libcontainer container 6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd.
Jan  6 14:19:30 aurora kernel: [269399.875680] eth0: renamed from veth385adb7
Jan  6 14:19:30 aurora kernel: [269399.903631] device enp4s0 entered promiscuous mode
Jan  6 14:19:30 aurora systemd[1]: docker-6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd.scope: Succeeded.
Jan  6 14:19:30 aurora dockerd[1469]: time="2022-01-06T14:19:30.872142719+13:00" level=info msg="ignoring event" container=6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan  6 14:19:30 aurora containerd[1091]: time="2022-01-06T14:19:30.872172889+13:00" level=info msg="shim disconnected" id=6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd
Jan  6 14:19:30 aurora containerd[1091]: time="2022-01-06T14:19:30.872216669+13:00" level=error msg="copy shim log" error="read /proc/self/fd/11: file already closed"
Jan  6 14:19:30 aurora kernel: [269399.932856] device enp4s0 left promiscuous mode
Jan  6 14:19:30 aurora kernel: [269399.975551] veth385adb7: renamed from eth0
Jan  6 14:19:30 aurora systemd-udevd[702371]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan  6 14:19:30 aurora systemd-udevd[702371]: Using default interface naming scheme 'v247'.
Jan  6 14:19:30 aurora NetworkManager[905]: <info>  [1641431970.9718] manager: (veth385adb7): new Macvlan device (/org/freedesktop/NetworkManager/Devices/8984)
Jan  6 14:19:30 aurora systemd-udevd[702371]: veth385adb7: Failed to query device driver: No such device
Jan  6 14:19:30 aurora systemd-udevd[702371]: veth385adb7: Failed to get link config: No such device
Jan  6 14:19:31 aurora systemd[1]: run-docker-netns-829ac6b4952c.mount: Succeeded.
Jan  6 14:19:31 aurora systemd[1309]: run-docker-netns-829ac6b4952c.mount: Succeeded.
Jan  6 14:19:31 aurora systemd[697551]: run-docker-netns-829ac6b4952c.mount: Succeeded.
Jan  6 14:19:31 aurora systemd[1309]: var-lib-docker-overlay2-7a603b953ddf4bd42baa7d453037fa632b44862a046e642661d044f986bd515f-merged.mount: Succeeded.
Jan  6 14:19:31 aurora systemd[1]: var-lib-docker-overlay2-7a603b953ddf4bd42baa7d453037fa632b44862a046e642661d044f986bd515f-merged.mount: Succeeded.
Jan  6 14:19:31 aurora systemd[697551]: var-lib-docker-overlay2-7a603b953ddf4bd42baa7d453037fa632b44862a046e642661d044f986bd515f-merged.mount: Succeeded.
Jan  6 14:19:43 aurora dockerd[1469]: time="2022-01-06T14:19:43.675912338+13:00" level=warning msg="macvlan driver does not support port exposures"
Jan  6 14:19:43 aurora NetworkManager[905]: <info>  [1641431983.6949] manager: (veth5cffd96): new Macvlan device (/org/freedesktop/NetworkManager/Devices/8985)
Jan  6 14:19:43 aurora systemd-udevd[702534]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan  6 14:19:43 aurora systemd-udevd[702534]: Using default interface naming scheme 'v247'.
Jan  6 14:19:43 aurora containerd[1091]: time="2022-01-06T14:19:43.708157277+13:00" level=info msg="starting signal loop" namespace=moby path=/run/containerd/io.containerd.runtime.v2.task/moby/6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd pid=702548
Jan  6 14:19:43 aurora systemd[1]: Started libcontainer container 6cfb7a28fd67bf1f0e50cec3afe107df7fd1dff1e292bdc886dfc0a72b61dedd.
Jan  6 14:19:43 aurora kernel: [269412.979697] eth0: renamed from veth5cffd96
Jan  6 14:19:43 aurora kernel: [269413.019621] device enp4s0 entered promiscuous mode
... keeps looping at this point

[robvdl]

Seems to be this https://forums.docker.com/t/docker-20-10-5-constant-error-level-error-msg-copy-shim-log-error-read-proc-self-fd-10-file-already-closed/106870

Related to this: containerd/cgroups#83
And this: moby/moby#40075

I also see "moby" in my logs, assuming that is part of Docker.

I tried adding swapaccount=1 to GRUB_CMDLINE_LINUX_DEFAULT and running update-grub and rebooting but still same thing.

Not sure where to go from here? I might look at running under KVM instead of Docker if this is too much trouble to get going.

[robvdl]

Sorry I haven't figured this out so have abandoned the idea of using Docker for 3CX and have gone down the path of running it on an Odroid HC1 I had lying around running Armbian buster, tricking the installer that it is a Raspbery PI because armbian buster is "close enough".

Still interested in the idea of one day using Docker, but for now I'm not going to pursue this any further. I don't quite understand why all the invidual processes aren't docker containers, but instead it's one container running systemd. It's not normally the way you dockerize things but I understand it could be a challenge dockerizing existing software to split it into individual containers.

[FirefoxNL]

I managed to get the latest image running on Ubuntu 22.04!

On Ubuntu it is the volume mount to /sys/fs/cgroups that seems to cause the crashing.

I followed the guide @ekondayan linked to to have docker use systemd insteam of cgroupsfs.
After that, create the container (or modify an existing container) without the -v /sys/fs/cgroup:/sys/fs/cgroup:ro mount.

Edit: I forgot that I turned on priviledged mode along the way. That needs to be on too.
Add --priviledged to the docker run command.

Then it boots right up without restarting.
I had apparmor disabled but re-enabling it doesn't seem to cause any issues.

I obviously haven't tested every possible aspect yet but the installer ran without issues, I can access the web portal through xxx.my3cx.nl and a call between my phone (connected to cellular, not WiFi) and my PC works perfectly including audio and video, and chats work too.