JDK-8228343 : JCMD and attach fail to work across Linux Container boundary
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-18
  • Updated: 2021-07-22
  • Resolved: 2021-06-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16 JDK 17 JDK 18
16u-cpuFixed 17 b26Fixed 18Resolved
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Use the latest version of tests from  8195809: [TESTBUG] jps and jcmd -l support for Docker containers is not tested

1. jcmd -l works across container boundaries. That is, if JCMD runs on the host system outside of the container, while the observed JVM process runs inside a container, the JCMD will see that process and report its PID. Important to note that for this to work, both UserName and UID of the JCMD and the observed process must match, which the test strives to do.

2. However, any other JCMD commands to the process running inside a container fails. 
The test uses simple "jcmd <PID> help", and that fails.

It seems that the signal is sent to the observed process, the process receives the signal, but JCMD and observed process fail to establish the communication.

================= Failure:
STDERR:
 stdout: [19761:
];
 stderr: [com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /proc/19761/root/tmp/.java_pid1: target process 19761 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:100)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:115)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:99)
]
 exitValue = 1


Comments
Fix was pushed while main bug was targeted to 18. Reset the main bug to fixed in 17 and copied the Robo Duke entry here.
10-06-2021

Changeset: bf29a011 Author: Kevin Walls <kevinw@openjdk.org> Date: 2021-06-09 20:45:44 +0000 URL: https://git.openjdk.java.net/jdk/commit/bf29a0115cc67ed2926b135b6b6ade5ff5ee84f6
10-06-2021

I was confident this all worked, and yes it did used to work... In the testcase being tried here, if I switch the JDK calling jcmd back to 11.x it works fine - jcmd attaches to the JVM (latest 17) running in the container. If I take latest jdk17 and backout this small change then it works again: 8214300: .attach_pid files may remain in the process cwd https://bugs.openjdk.java.net/browse/JDK-8214300 In watching the problem in strace I saw reference to /.attach_pid1 and logging in open/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java I see that we change: f = /proc/12777/cwd/.attach_pid1 ..to: f = /.attach_pid1 ...with f.getCanonicalFile(); and the target JVM does not see the attach file.
28-05-2021

This seems to be a case of AttachListener::is_init_trigger[1] and VirtualMachineImpl.createAttachFile[2] disagreeing. The former looks in $(pwd)/.attach_pid<pid> or /tmp/.attach_pid<pid> and the latter creates it in /proc/<pid>/root/tmp/.attach_pid<ns_pid>. [1] http://hg.openjdk.java.net/jdk/jdk/file/ba72dac556c3/src/hotspot/os/linux/attachListener_linux.cpp#l500 [2] http://hg.openjdk.java.net/jdk/jdk/file/ba72dac556c3/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java#l295 Note that this code in VirtualMachineImpl.java has been changed to its current form for JDK-8179498. So a fix for it would have to ensure both cases work. Cross container monitoring (via sidecar), as well as attaching into a JVM *inside* a container from the outside (host).
18-07-2019