forked from containers/podman
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
top: do not depend on ps(1) in container
This ended up more complicated then expected. Lets start first with the problem to show why I am doing this: Currently we simply execute ps(1) in the container. This has some drawbacks. First, obviously you need to have ps(1) in the container image. That is no always the case especially in small images. Second, even if you do it will often be only busybox's ps which supports far less options. Now we also have psgo which is used by default but that only supports a small subset of ps(1) options. Implementing all options there is way to much work. Docker on the other hand executes ps(1) directly on the host and tries to filter pids with `-q` an option which is not supported by busybox's ps and conflicts with other ps(1) arguments. That means they fall back to full ps(1) on the host and then filter based on the pid in the output. This is kinda ugly and fails short because users can modify the ps output and it may not even include the pid in the output which causes an error. So every solution has a different drawback, but what if we can combine them somehow?! This commit tries exactly that. We use ps(1) from the host and execute that in the container. Now unfortunately because ps(1) is dynamically linked (at least on the mainstream distros) this is not trivial. The trick here is in theory simple, open the binary on the host then we have a fd for it and can refer to the path via /proc/self/fd/<NUM>. Now join the container mount and pid ns then simple execute the fd path. That fails quickly because the linker will try to load the shared libs and because we are in a different mount ns that fails. Now to solve this we use the same trick with the LD_PRELOAD variable basically to make the linker load the opened libs on the host via the fd paths. Except that still don't works because even the linker in the container can be different. Compare glibc vs musl based distros. So we first have to get the right linker path and open this one as well in order to execute it directly. Now because we execute the linker directly we can no longer use the LD_ vars and have to set the cli arguments directly, i.e. --preload. In order to get the actual linker path and shared libraries we first execute ldd(1) to get the output. We can then parse that and open all correct paths. If we have a static binary we can skip all that and just execute it directly on the host, we assume it is static if ldd fails. Technically this could be a breaking change if somebody does not have ps on the host and only in the container but I find that very unlikely so I have removed the in container fallback. This updates the docs accordingly, note that podman pod top never falls back to executing ps in the container as this makes no sense with multiple containers so I fixed the docs there as well. Fixes containers#19001 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2215572 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
- Loading branch information
Showing
7 changed files
with
148 additions
and
44 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters