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/<pid>/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!)

one could compare the /proc/<pid>/ns/mnt if they are the same the processes share the same mount namespace - which by

the 'target' JVM should (always) create the attach socket in its /proc/self/root/tmp directory...
2. jcmd treats it as a heuristic and attempts each way during the socket file read - 
first /proc/<pid>/root/tmp and then /tmp.

this was my thought also if the "attacher" JVM and the "attachee" are not in the same (mount or pid) namespace then it seems highly unlikely that they can communicate via a filesystem namespace mechanism.

3. jcmd has some option or environment variable where the user can tell it the 
socket file path.

we could do this but this would require a filesystem in common as with the existing "attach a shared volume" solution

Do you agree that these are the types of choices available?

Thanks,
Jim


Reply via email to