glibc 2.34 upgrade will break some essential services
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
docker.io (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
glibc (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Try this:
$ lxc launch ubuntu-daily:impish test-docker
$ lxc shell test-docker
# cat <<EOF >/etc/apt/
deb http://
EOF
# apt update
# apt install libc-bin -y
...
(debconf query asking which services should be restarted. Just select Ok)
...
Restarting services...
systemctl restart accounts-
Job for systemd-
See "systemctl status systemd-
Job for systemd-
See "systemctl status systemd-
Service restarts being deferred:
/etc/needresta
systemctl restart networkd-
systemctl restart systemd-
systemctl restart unattended-
# ping ubuntu.com
ping: ubuntu.com: Temporary failure in name resolution
# systemctl status systemd-networkd
× systemd-
Loaded: loaded (/lib/systemd/
Active: failed (Result: exit-code) since Wed 2021-09-01 20:41:03 UTC; 36s ago
TriggeredBy: × systemd-
Docs: man:systemd-
Process: 2411 ExecStart=
Main PID: 2411 (code=exited, status=217/USER)
Sep 01 20:41:03 test-docker systemd[1]: systemd-
Sep 01 20:41:03 test-docker systemd[1]: Stopped Network Service.
Sep 01 20:41:03 test-docker systemd[1]: systemd-
Sep 01 20:41:03 test-docker systemd[1]: systemd-
Sep 01 20:41:03 test-docker systemd[1]: Failed to start Network Service.
The same can be reproduced inside a VM. If the user reboots the system, it becomes usable again.
[ Original Description ]
This bug is blocking docker.io on update-excuses.
I noticed that docker.io version 20.10.7-0ubuntu2 (currently in impish-proposed) is failing to start when installed inside an Impish LXD container. You can reproduce the bug by doing:
$ lxc launch ubuntu-daily:impish test-docker -c security.
$ lxc shell test-docker
# cat <<EOF >/etc/apt/
deb http://
EOF
# apt update
# apt install docker.io -y
...
Setting up docker.io (20.10.7-0ubuntu2) ...
Adding group `docker' (GID 120) ...
Done.
Created symlink /etc/systemd/
Created symlink /etc/systemd/
A dependency job for docker.service failed. See 'journalctl -xe' for details.
invoke-rc.d: initscript docker, action "start" failed.
○ docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/
Active: inactive (dead)
TriggeredBy: × docker.socket
Docs: https:/
Sep 01 01:52:47 test-docker systemd[1]: Dependency failed for Docker Application Container Engine.
Sep 01 01:52:47 test-docker systemd[1]: docker.service: Job docker.
...
Investigating a bit more, here's what we see when we check the status of docker.socket:
# systemctl status docker.socket system/ docker. socket; enabled; vendor preset: enabled)
× docker.socket - Docker Socket for the API
Loaded: loaded (/lib/systemd/
Active: failed (Result: exit-code) since Wed 2021-09-01 02:05:47 UTC; 14s ago
Triggers: ● docker.service
Listen: /run/docker.sock (Stream)
Sep 01 02:05:47 test-docker systemd[1]: Starting Docker Socket for the API.
Sep 01 02:05:47 test-docker systemd[2488]: docker.socket: Failed to resolve group docker: No such process
Sep 01 02:05:47 test-docker systemd[1]: docker.socket: Control process exited, code=exited, status=216/GROUP
Sep 01 02:05:47 test-docker systemd[1]: docker.socket: Failed with result 'exit-code'.
Sep 01 02:05:47 test-docker systemd[1]: Failed to listen on Docker Socket for the API.
What caught my attention is the following line:
Sep 01 02:05:47 test-docker systemd[2488]: docker.socket: Failed to resolve group docker: No such process
It doesn't make sense to me. As can be seen in the bug description, the "docker" group was properly created *before* the service/socket was (tentatively) started.
If we inspect the socket, we see that its group is indeed wrong (it should be "docker", but it's "root"):
# ls -la /var/run/ docker. sock docker. sock
srw-rw---- 1 root root 0 Sep 1 02:05 /var/run/
What's strange is that systemd should be responsible for changing the ownership of the socket when the service is started, but it can't (because it fails to "resolve" the "docker" group). strace wasn't very helpful to determine what's going on here.
It's also interesting to note that I can't reproduce the problem with docker.io 20.10.7-0ubuntu1 (from impish-release). The installation finishes just fine.
I noticed that the last upload was about shipping libnetwork into the golang- github- docker- docker- dev package. Initially I don't see how this could have impacted the docker installation here. Maybe libnetwork is messing with the socket creation somehow?