The JDK-8179498 fix improved the usage of the serviceability tools for interacting with Linux containers but has a few drawbacks.  This solution requires that the client tools being run on a host attempting access to container based Java processes must be run as root.  The other problem is that this solution is Linux specific and can't be supported by Mac or Windows hosts.

Cloud based monitoring software that would like to utilize jcmd in order to enable and get access to JFR recordings or Java Heap dumps for containerized process must open up security holes to make use of the previous fix on Linux and can't even use jcmd for Windows or Macs.

Here's one possible solution to this set of problems:

Modify the JDK to add a new Java property jdk.attach.tmpdir which will optionally alter the location where the attach files, communication and socket files are stored in order to add support for containers. This property could also be extracted from an environment variable such as JDK_ATTACH_TMPDIR.

This is needed since accessing /proc/*/root/tmp requires root privs and is not available on other operating system platforms.

This proposal redirects the file access to the hosts tmp directory so accesses are handled that same way as local Java processes.

All containers that startup and run Java would have to use these additional options to enable this:

Example:

Java:  -Djdk.attach.tmpdir=/container-attachdir -XX:+UnlockCommercialFeature -XX:+FlightRecorder -XX:+StartAttachListener
Docker:  --volume /tmp/container-attachdir:/container-attachdir

This fix has to also use more than just the pid for the naming of the files in $jdk_attach_dir/hsperfdata_{user}/{pid} and $jdk_attach_dir/.java_pid{pid} since we'll have no way of mapping these pids to host pids.  The name of the container along with the local container pid in all places the original host pid was used.  The hostname for containers (/etc/hostname) is typically the containerid.

-XX:+StartAttachListener must be specified for container processes since the normal signal handshaking currently used to initiate an attach cannot be used since there is no way of associating a container pid with a host pid without root access.

For example:

$jdk_attach_dir/hsperfdata_{user}/e4f3e2e4fd97:10
$jdk_attach_dir/.java_pid:e4f3e2e4fd97:10

With all this in place, jcmd running on the host can initiate a JFR to dump of a recording from each container to the hosts /tmp/container-attachdir/e4f3e2e4fd97:10/recording.jfr file.