Hello!
I am a docker newbie. Searching the web and this forum I could not find a similar problem or a solution for this, so I try to describe my problem here.
My setup is ProxmoxVE → a VM dedicated for docker containers (created with a proxmox helper script, OS is Debian) → three docker containers on that VM (immich, jellyfin, paperless-ngx).
For a while, everything worked fine. To my knowledge, I did not change anything important, but suddenly, when I booted the VM I get a continuous loop of messages in the console of the VM and it never reaches the state where I can login. The first messages are:
"
br-8ca1b9071583: port 1(vethb702ae9) entered blocking state
br-8ca1b9071583: port 1(vethb702ae9) entered disabled state
device vethb702ae9 entered promiscuous mode
br-8ca1b9071583: port 1(vethb702ae9) entered blocking state
br-8ca1b9071583: port 1(vethb702ae9) entered forwarding state
br-8ca1b9071583: port 1(vethb702ae9) entered disabled state
br-e51380cb727a: port 3(veth262483d) entered disabled state
vethe1f2c0b: renamed from eth0 eth0: renamed from vethbccecb2
IPv6: ADDRCONF(NETDEV_CHANGE): vethb702ae9: link becomes ready
br-8ca1b9071583:port 1(vethb702ae9) entered blocking state
…"
This continues endlessly (I waited for 2-3 hours) with different br-… or ports
When I start the VM without starting docker, these messages do not appear and I can login to the console. When I type ‘docker ps’ the loop of messages appears again.
Does anyone know this and might even have an idea what I could do? I would be very happy.
Cheers, Paul
That is a sign of containers created and and maybe also deleted. I don’t remember which log appears when.
What I saw often is that when I boot the OS, network related settings, issuescan slow down the booting process, but after about 2 minutes, it usually continues. It is worse when more than one delay happens, but I don’t see why running Docker would block the entire booting process. I understand thaty ou waited 2-3 hours so that is wy more than normal
We had multiple Proxmox related issues. I don’t remember endless booting loop, but I know proxmox related issues are not rare. I would recommend this the following topic, especially the last post:
The original issue is different but you could still check if apparmor is enabled and what happens if you disable it. (even if it worked for you before)
You mean the VM was created with those scripts? That shouldn’t matter.
Can you also share the output of docker info and docker version? Remove any private info from the output before sharing like IP, domain, username and so on. When you share the outputs, please, use code blocks like this:
```
output here
```
So 3 backticks before and after the code if you are using the markdown based message composer.
But based on the logs, it is suspicious that the eth0 interface was renamed after the container-related logs. Could be totally normal. I am not sure. If Docker, containerd or runc were automatically updatd, that could also cause problems.
Thank you, rimelek, for the link and your suggestions!
First of all, yes, I meant the VM was created with the proxmox helper script but the script installed docker on it automatically as well.
Unfortunately, when I type docker info the endless loop starts, same with docker version. I managed to pause the vm immediately after I typed docker info and the output started like this:
audit: type=1400 audit(1764271175.886:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="docker-default" pid=421 comm="apparmor_parser"
Initializing XFRM netlink socket
bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
After that I assume it is the looping messages that I wrote in my original post, but its way too fast to catch them on the console.
It seems that there is AppArmor used, right? I read the post you mentioned and AppArmor only seems to be an issue if docker container are used on the proxmox host directly. Many suggest to use docker container in an qemu VM which I do have. Do you think I still should disable AppArmor?
Qemu vm’s are not affected: a vm is isolated from the hosts.
I run docker v29 in a qemu vm on Proxmox. The only difference is, that I use Ubunt 24.04 instead of Debian.
Though, it’s a whole different thing if lxc containers are used. We had reports about them being affected as well.
Since I never really used proxmox, I just shared the link until we found a better clue. I didn’t think about the reasons much. I knew @meyay would eventually step in
So where did the error messages appear? In the same terminal where you ran docker info? Or in the system logs?
When you ran docker info, was the daemon running already? If not, I guess the docker.socket service was still running so when you run a docker command that tries to access the socket, the daemon starts.
So since you can’t share the output of docker info, can you share the output of the following command?
dpkg -l 'docker*' | grep '^ii'
Another idea: Since your logs showed that containers tried to start (networks were created), it is possible that one of your containers run something that is not compatible with something on the host. Just an example from my experience: When I tried running systemd in containers incorrectly, when I started the container with systemd in it, I lost my graphical interface immdiately. To investigate this idea, you would need to stop all containers before you can run the docker command to stop them… so I will continue thinking about this.
Yes, in the same terminal. Where would I find the right log? Maybe there would be more information there than I could capture in my attempts with pausing the VM.
When you ran docker info, was the daemon running already? If not, I guess the docker.socket service was still running so when you run a docker command that tries to access the socket, the daemon starts.
I think I disabled the autostart of the docker daemon when the VM starts, but I am not very sure. How can I check if the daemon was running? Sorry for my incompetence.
The command:
dpkg -l 'docker*' | grep '^ii'
led to this output:
ii docker-buildx-plugin 0.29.1-1~debian.12~bookworm amd64
ii docker-ce 5:28.5.2-1~debian.12~bookworm amd64
ii docker-ce-cli 5:28.5.2-1~debian.12~bookworm amd64
ii docker-ce-rootless-extras 5:28.5.2-1~debian.12~bookworm amd64
ii docker-compose-plugin 2.40.3-1~debian.12~bookworm amd64
Thanks again for the time you invest into my problem!
Cheers, Paul
But yoz can alos try without -u docker so you can see othe rlogs, not just docker daemon related logs.
You may need to navigate back to older logs whouc you could do by passing --since <VALIDTIMESTAMP> or just increasing the number of lines by passing --lines <NUMBEROFLINES> like journalctl -e --lines 10000. Or you can probably find the same in /var/log/syslog.
There are two units. One is “docker.service”, the other is “docker.socket”. The socket unit can run even when you disable docker itself. That means the daemon doesn’t start after reboot, but starts when you run any docker command that uses the socket which is detected by the docker.socket systemd unit.
Thanks for the output. So you are using docker-ce and a not very old version.
Regarding restart policy, I would probably make a backup of the docker data root and delete all container definitions manually. Then start the daemon and try running the docker info command. I am just not sure what happens when you delete the container definitions manually. I should try first in a test VM. Or you can too if you have a test VM.
Thanks for the hint on journalctl! I got the docker log, which shows lots of warning messages and ignoring events. Unfortunately, I don’t understand any of it. I tried to upload a version of it as .txt but as new user I am not allowed.
What I can see is that docker.service starts indeed after I type e.g. docker ps in the terminal. After it started (with lots of above mentioned messages), there is only one message repeating with different IDs after container=...
At the moment I do not have a test VM. I can of course create one, I am just not sure I would know how to do all the things you suggested.
I am very sorry that I am such a rookie! I try to keep up…
