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.
Erik
Hey,
I’ve attached a version rebased on jdk10, it also (currently) applies cleanly
to jdk9.
While there is no supplied test or harness for this patch, how I built and
tested is
available at https://github.com/tjfontaine/jdkbuild (there’s also a preview of
my
follow on patch for pathmap_open as well).
Thanks!
TJ
On 4/28/17, 3:47 PM, "serviceability-dev on behalf of TJ Fontaine"
<serviceability-dev-boun...@openjdk.java.net on behalf of tj.fonta...@oracle.com> wrote:
I had no doubt we’d end up on the conversation of 10 -> 9 -> 8u, I started
with 8u merely because it was representative of today’s customer pain. I’ll be sure
to work on retargeting it as well.
Thanks!
TJ
On 4/28/17, 3:42 PM, "David Holmes" <david.hol...@oracle.com> wrote:
Hi TJ,
Thanks for the patch (I haven't looked at it yet). FYI at the moment,
unless this is considered a high priority bug for JDK 9 it has to be
targeted to JDK 10, and then possibly backported to 9 and 8u.
Cheers,
David
On 29/04/2017 8:23 AM, TJ Fontaine wrote:
> 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
>
