1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<think>
Okay, I need to classify this bug report as either 'user' or 'system' mode related. Let's see what the problem is about.
The user reports that a command hangs in a CentOS 7 arm64 container running on an Ubuntu 22 amd64 host using Docker. The specific command they ran was `LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true &`. When they checked the process status with `ps`, they saw that two processes were in a 'R' state (running), which means they're consuming CPU.
The first thing I notice is that this involves Docker and QEMU because the container is arm64, and the host is amd64. So Docker must be using QEMU binfmt_misc to emulate the arm64 architecture. The processes in question are `/usr/libexec/qemu-binfmt/aarch64-binfmt-P`, which suggests they're related to the QEMU user-mode emulation.
The steps to reproduce indicate that this issue occurs on an Ubuntu 22 amd64 host but not on an Ubuntu 20.04 host or a native arm64 machine without QEMU. This points towards something specific about the setup when using QEMU for emulation on the Ubuntu 22 system.
Additional info mentions that other images built by their team don't have this issue, so it's isolated to this CentOS 7 image. They tried updating QEMU but didn't replace the binfmt interpreter, which might mean they're still using an older version causing the problem.
The user also tried building `trace-cmd` but couldn't get events for KVM, suggesting that maybe system-mode issues aren't being captured here. Since the issue occurs in a container and involves QEMU's user-mode process (`aarch64-binfmt-P`), it seems more like a user-space emulation problem rather than something at the hypervisor or kernel level.
In QEMU, there are two main modes: user mode (which emulates individual processes) and system mode (which emulates an entire OS). Since this issue is about a single process hanging in a container, it's likely related to user-mode emulation where QEMU runs each arm64 binary through its interpreter. The fact that the problem occurs only when using QEMU on amd64 suggests a bug in how QEMU handles certain binaries or their interactions with the host's libraries.
Moreover, since the command is `/lib64/ld-2.17.so --list /usr/bin/true`, which is a dynamic linker command, it might be getting stuck while trying to resolve dependencies or map symbols, possibly due to an issue in how QEMU handles this process in user mode.
Given all these points, the bug seems related to QEMU's user-mode operation rather than system-level issues like device emulation or kernel interactions. Therefore, it's a 'user' mode problem.
</think>
The issue is occurring within the context of QEMU's user-mode emulation where the dynamic linker command is hanging. It doesn't involve higher-privilege operations or system devices but is specific to process execution in user space.
user
|