Thank you, Larry - that /proc//ns/mnt test makes a lot of sense to me, and
I learned something new today!
Jim
-Original Message-
From: serviceability-dev On Behalf Of
Laurence Cable
Sent: Wednesday, May 1, 2024 8:44 PM
To: serviceability-dev@openjdk.org
Subject: Re: 8327114: Attach in Linux may have wrong behaviour when pid ==
ns_pid (Kubernetes debug container)
**Warning! This email originated from outside the organization. Do not open
attachments unless you recognize the sender. If you suspect this email is
malicious, use the "Report Email" button.
Replies to this email will go to serviceability-dev-r...@openjdk.org .**
just to demonstrate:
$ docker run -it --name=js1 openjdk:17.0.1-jdk /bin/jshell ...
$ docker run -it --name js2 --pid=container:js1 openjdk:17.0.1 /bin/jshell
$ docker exec -it js1 bash
bash-4.4# ls /tmp/hsperfdata_root
1 26
bash-4.4# readlink /proc/26/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/26/ns/mnt
mnt:[4026532747]
bash-4.4# exit
[lpgc@arran ~]$ docker exec -it js2 bash bash-4.4# ls /tmp/hsperfdata_root
107 82
bash-4.4# readlink /proc/107/ns/pid
pid:[4026532751]
bash-4.4# readlink /proc/107/ns/mnt
mnt:[4026532941]
you will note that the JVM pid: 26 and 107 occupy the same pid namespace
(4026532751) but occupy different mnt namespaces (4026532747, 4026532941)
therefore attempting to attach via '/tmp' will fail, /proc//root/tmp must
be used to rendezvous
- Larry
On 5/1/24 2:03 PM, Doyle, James, K wrote:
> Hi Sebastian,
>
>> I think I can confirm that there is a regression.
> Thanks for reproducing the regression, your test makes sense to me, and I
> think it is similar to the scenario we have with Kubernetes debug containers
> (separate filesystems, but same PID namespace).
>
> I noticed some of the other recent Pull Request comments on
> https://github.com/openjdk/jdk/pull/17628:
>
>> should it not be comparing pid namespace ids and not pids?
> and wanted to give a little feedback. I think more refined approaches to
> figuring out whether the target JVM is in the same PID namespace make sense
> and could be an improvement, but it's still different from figuring out
> whether the target JVM has the same filesystem (specifically, I guess, the
> filesystem containing /tmp or java.io.tmpdir). That seems like the crucial
> thing for deciding what socket file path to read, and whether /tmp is
> sufficient or /proc//root/tmp is needed. I can think of a couple
> different approaches to the filesystem issue:
>
> 1. There is some Linux kernel information that can be obtained about
> the jcmd process and the target JVM process to figure out unequivocally what
> their root filesystems are from the host's point of view, and whether they're
> the same. (I don't know what this might be, though!) 2. jcmd treats it as a
> heuristic and attempts each way during the socket file read - first
> /proc//root/tmp and then /tmp.
> 3. jcmd has some option or environment variable where the user can tell it
> the socket file path.
>
> Do you agree that these are the types of choices available?
>
> Thanks,
> Jim
>
