[PATCH] attach in linux should be relative to /proc/pid/root and namespace aware

[serguei.spitsyn at oracle.com]

Hi TJ,

The fix looks good to me, modulo the suggestion from David about the 
comment at L345.
However, I'm not an expert in the namespaces area.
It'd be nice to hear from other people.

This has to be tested at least when the namespaces are not present.
Testing should include the J*tools (jcmd, jstack, jmap, etc.) and the 
attach API tests.
Not sure, if you can run them.
But your sponsor, Erik, can probably run them for you.

Also, it would be nice to have one new Jtreg test verifying this patch 
with a namespace.
Not sure, it is a strong requirement though.


Erik,

Thank you for sponsoring this patch!
David has already created the webrev:
http://cr.openjdk.java.net/~dholmes/8179498/webrev/


Thanks,
Serguei


On 5/2/17 16:51, Erik Gahlin wrote:
> I am not a (R)eviewer, so I can't give it my blessings, but I can 
> sponsor it.
>
> I will create a webrev so it easier to review.
>
> Erik
>
>> I have attached a patch that allows jcmd to work against a java 
>> process running
>> inside a Docker container. Apologies if this is not in the correct 
>> format. It was
>> built against jdk8u. I couldn’t seem to find an existing JIRA for it.
>>
>> Diagnostic commands (i.e. jcmd, jstack, etc) fail to attach to a 
>> target JVM
>> that is inside a container (e.g. Docker).
>>
>> A Linux container often isolates a process in a PID and Mount 
>> namespace that is
>> separate from the "root container" (analogous to the hypervisor/dom0 in
>> hardware virtualization environments, or the global zone on Solaris). 
>> A target
>> JVM that is isolated in either a PID namespace, or a Mount namespace 
>> will fail
>> the attach sequence.
>>
>> When the target JVM is in its own PID namespace the pid of the 
>> process is
>> distinct from what the real pid of the process as it relates to the root
>> container. For example, in the root container you can observe a JVM 
>> with a pid
>> of 17734, however if that JVM is running inside a Docker container 
>> the pid
>> inside its PID namespace is likely 1. So when the target JVM receives 
>> the
>> SIGQUIT it looks in /proc/self/cwd/ for .attach_pid1 however the 
>> external
>> attaching JVM has created the file /proc/17734/cwd/.attach_pid17734. 
>> Given this
>> discrepancy the target JVM will output to stderr thread status, since
>> /proc/self/cwd/.attach_pid1 doesn't exist and won't continue with the 
>> attach
>> sequence.
>>
>> The solution is to parse /proc/pid/status for the field NSpid 
>> (available since
>> Linux 4.1) which contains a list of pids, where the last entry is the 
>> "inner
>> most" PID namespace value. (Namespaces can be stacked, unlike Solaris 
>> Zones
>> which have a virtualization depth of 1)
>>
>> The rest of the Linux attach sequence assumes a shared mount 
>> namespace by
>> waiting for /tmp/.java_pid17734 to appear. But if the attaching 
>> process is in a
>> separate namespace because the target JVM is in a mount namepsace (or 
>> in a
>> chroot as well) the unix domain socket for attaching won't appear.
>>
>> Instead the attach sequence should resolve file names relative to
>> /proc/17734/root which has a materialized view of the rootfs for the 
>> target.
>>
>> Thanks!
>>
>> TJ
>>
>