Understanding User UID Mappings in Containers Using the htop Command

During routine emergency procedures and troubleshooting, I often use the htop command or top and find many users represented by numbers. However, when I check /etc/passwd, there are no corresponding users, and the directories and executable files in the /proc directory of the process do not exist. This article addresses some technical doubts I had at work through practical experience.

Taking the user represented by 33 as an example, the corresponding pid is 19390.

And since the paths and files do not exist, it indicates that the files are not on the host machine.

We switch to the htop command to check. We find that the parent process of this apache2 in the process chain is containerd-shim-runc-v2, which indicates that apache2 is a process within a container.

Since the files are within a container, it explains why the host machine cannot open them.

Thought 1: So does the user corresponding to the number 33 represent a user within the container?

Enter the container to view process information.

Corresponding to the uid number of the www-data user in /etc/passwd.

This explains why the process user seen as a number when executing the top command on the host machine.

Thought 2: Why can’t the www-data in the container be displayed on the host machine, but corresponds to the uid?

My guess is that this uid is actually a mapping. To prove my idea.

Take the games user as an example, modify /etc/passwd, and change its uid from 12 to 33 for testing.

Check again with the htop command.

It turns out that the original 33 has become games.

This means that the uid of the user of the process in the container is displayed by looking up /etc/passwd on the host. Originally, there was no user with uid 33 on the host, so it displayed the uid of the user in the container (as a number). After I changed the uid, it displayed the corresponding username.

Therefore, it is very likely that the user of the process seen through commands like top on the host is incorrect!

Similarly, the user corresponding to apache2 -DFOREGROUND forked from the container shown as root is not the root user on the host, but just happens to have uid 0 within the container, which maps to 0 on the host, i.e., the root user.

So although apache2 -DFOREGROUND and containerd-shim-runc-v2 above both show the user as root, their meanings are completely different.

Thought 3: What is the difference between the top on the host and the top inside the container?

I also installed the htop command inside the container, and the CPU and memory information here is consistent with the host, but the process information is different.

/proc is a pseudo-filesystem that exists in memory rather than on the hard disk. Through it, you can interact with the kernel’s internal data structures to obtain useful information about processes. /proc contains the following files:

• /proc/cpuinfo – Information about the CPU (model, family, cache size, etc.)
• /proc/meminfo – Information about physical memory, swap space, etc.
• /proc/mounts – List of mounted filesystems
• /proc/devices – List of available devices
• /proc/filesystems – Supported filesystems
• /proc/modules – Loaded modules
• /proc/version – Kernel version
• /proc/cmdline – Kernel command line parameters input at system startup
• /proc/{pid} – Process information

top retrieves current memory and CPU information through /proc. Docker containers share the operating system kernel, and when a container starts, it mounts some files from /proc. Whether you can see memory and CPU information in Docker through top mainly depends on whether these files are mounted.

Do you need to manually mount these files? Generally, no. The amount of mounted content usually depends on the image. General Red Hat/Ubuntu images will mount memory and CPU information, while streamlined Docker images will have less information, and sometimes the information obtained by top is not comprehensive.

Based on the above analysis, the amount of information seen by top depends on the content in /proc. Due to the isolation of the pid namespace, the pid information of the host will not be mounted by the started container, so the host processes outside the container cannot be seen.

Extended Thought 4: Can the host’s processes be monitored from within the container?

In Docker, you can use the “–pid” parameter to bring the host’s pid namespace into the container, allowing you to see the host’s processes directly within the Docker instance.

Using busybox as an example, when the container is normally started, the /proc directory only contains process information within the container.

When starting the container with the –pid=host parameter, the /proc directory on the host will be mounted into the container, allowing you to monitor all the host’s processes from within the container.

Summary: Although this issue is technically insignificant, i.e., the incorrect mapping relationship caused by top for the user uid of processes within the container on the host through /etc/passwd. I feel this is more about enhancing problem-solving and exploration capabilities.