RFR(S): 8195809: [TESTBUG] jps and jcmd -l support for Docker containers is not tested

Severin Gehwolf sgehwolf at redhat.com
Tue Jul 30 09:05:45 UTC 2019

Hi Misha,

One question:

Is it expected for a root user (outside a container) to see *all* Java
processes inside a container?

As far as I understand it, these tests assert that the same user
(outside) and inside a container can see each other's Java processes.

Review is below...

On Mon, 2019-07-29 at 20:46 -0700, mikhailo.seledtsov at oracle.com wrote:
> Please review this change that:
>    - adds test case for "jcmd -l" and "jcmd <pid> help" where jcmd is 
> executed on a host/node outside the container,
>      while a targeted JVM is running inside a container
>    - factors out some common functionality to DockerTestUtils and 
> docker.Common
> Please note:
>    - the "jcmd -l" works in this configuration, however the JCMD's and 
> Target's username and UID have to match
>      (per design)
>    - the "jcmd help", "jcmd JFR.start" or any other JCMD command besides 
> "jcmd -l" does not work in this configuration
>      (Filed "JDK-8228343: JCMD and attach fail to work across Linux 
> Container boundary")
>      The test case is commented out, however can be used for reproducing 
> the issue, and will be enabled
>      once the bug is fixed.
>      JBS: https://bugs.openjdk.java.net/browse/JDK-8195809
>      Webrev: http://cr.openjdk.java.net/~mseledtsov/8195809.00/

+    // find process ID from JCMD output
+    public static long findPidFromJcmdOutput(OutputAnalyzer out, String name) throws Exception {
+        List<String> l = out.asLines()
+            .stream()
+            .filter(s -> s.contains(name))
+            .collect(Collectors.toList());
+        if (l.isEmpty()) {
+            throw new RuntimeException("Could not find matching process");
+        }
+        String psInfo = l.get(0);

This seems to assume there is exactly one matching line. In that case,
I'd suggest to amend the "l.isEmpty()" condition to:

if (l.isEmpty() or l.size() > 1) ...

     public static void
-        buildDockerImage(String imageName, Path dockerfile, Path buildDir) throws Exception {
+        buildDockerImage(String imageName, Path dockerfile,
+                         Path buildDir, String additionalDockerfileContent) throws Exception {
-                           DockerfileConfig.getBaseImageVersion());
+                           DockerfileConfig.getBaseImageVersion(),
+                           additionalDockerfileContent);
         try {
             // Build the docker
             execute(Container.ENGINE_COMMAND, "build", "--no-cache", "--tag", imageName, buildDir.toString())
-                .shouldHaveExitValue(0);
+                .shouldHaveExitValue(0)
+                .shouldContain("Successfully built");

If you assert "Successfully built" in the output it'll break podman
support. See 


+        // In order for jcmd to work, the USER name and UID of the observer
+        // need to match the USERNAME/UID of the observed JVM process
+        String additionalDockerFileContent =
+            String.format("RUN useradd %s --uid %d \n", getCurrentUserName(), getCurrentUserId()) +
+            String.format("USER %s \n", getCurrentUserName());

Perhaps the test should have a more telling class name. Perhaps
TestJcmdMatchingUsernames. Failing that, add this info the @summary tag
of the test?


  80             // JCMD does not work in sidecar configuration, except for "jcmd -l".
  81             // Including this test case to assist in reproduction of the problem.
  82             // t.assertIsAlive();
  83             // testCase03(mainProcPid);

Shouldn't this refer to JDK-8228343 as well? I believe a fix for JDK-
8228343 should cover both test cases.


>      Testing:
>        - ran the new test multiple times on Linux-x64
>        - ran TestJCMDWithSideCar multiple times on Linux-x64
>        - ran all Docker/Container tests (HotSpot and JDK)
>      All PASS
> Thank you,
> Misha

More information about the hotspot-runtime-dev mailing list