[PATCH] attach in linux should be relative to /proc/pid/root and namespace aware
Chris Plummer
chris.plummer at oracle.com
Fri Aug 18 00:15:35 UTC 2017
Hi TJ,
JDK-8179498 is assigned to me. I've been playing around with your
changes to make sure they work fine, and plan on sponsoring the commit.
I did run into one issue. It ended up being user error, but highlights a
gap in the jcmd docker support. More specifically, "jcmd -l" and "jcmd
<MainClass>" don't work. jcmd on the host has no visibility into the
list of JVM pid's running on the docker. Normally this list is obtained
by looking in /tmp/hsperfdata_<user>/* to find the list of JVM pid's for
each user. However, since the docker maps to a different /tmp, jcmd on
the host does not see these tmp files for docker JVMs. Thus you first
need to find the pid of the JVM running on the docker using ps on the
host, and then run jcmd using "jcmd <pid>". Because of this for quite a
while I thought your changes were not working, but when I dug more into
the attach API and learned how "jcmd -l" discovers the list of JVM
pid's, I realized my error, and everything was fine when I specified a
PID. This should probably be documented somewhere, at the very lead in
the release notes for 10.
Regarding any cleanup of the changes, the only thing I noted was the
following comment from Erik and your reply:
> On Wed, May 03, 2017 at 03:14:29PM +0200, Erik Gahlin wrote:
> >/I noticed thatgetNamespacePid throws IOException and
> InvalidPathException. />/Perhaps we want to catch those, so we can default to the original pid if />/there is a I/O related problem. /
> That seems reasonable, I'll add that.
Is there a webrev that has this change? The only one I have access to is
the following that David setup before this change was suggested:
http://cr.openjdk.java.net/~dholmes/8179498/webrev/
As for testing, I've verified that at least jcmd works between a docker
container and its host, and I will verify that these changes don't break
anything when the tool and the target JVM are on the same host. What
will be a challenge is verifying that all our tests pass when the target
JVM is in a docker container. I assume the tests simply spawn a JVM
process to attach to, so default behavior is always same host. It is
likely far from trivial to modify them to spawn the process in a docker.
Any suggestions?
thanks,
Chris
More information about the serviceability-dev
mailing list