On Wed, 7 Jan 2026 04:27:46 GMT, Yasumasa Suenaga <[email protected]> wrote:
>> We can see several thread dump on the console of Distroless nonroot JDK when
>> we attach debug (root) Distroless container image to the nonroot container
>> as following. It is not expected.
>>
>>
>> $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z
>> --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp
>> /opt/LongSleep -Xlog:attach=debug LongSleep
>> [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1
>> 2025-12-17 06:34:37
>> Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing):
>>
>> Threads class SMR info:
>> _java_thread_list=0x000078a8bc13f200, length=10, elements={
>> 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0,
>> 0x000078a8bc12ae40,
>> 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0,
>> 0x000078a8bc1317d0,
>> :
>>
>>
>> Attach API put `.attach_pid<pid>` file at first to clarify subsequent
>> SIGQUIT means create AttachListener thread. That file attempt to create on
>> current work directory of the target process, but it would fallback to /tmp
>> if failed (e.g. attacher cannot write onto work directory).
>>
>> In case of attaching nonroot container from root container, and also it
>> would fail due to lack of write permission on current work directory, and
>> cannot access /proc/<PID>/root/tmp. It causes following error on jcmd:
>>
>>
>> $ podman run -it --rm --pid container:debuggee --entrypoint sh
>> gcr.io/distroless/java25-debian13:debug
>> / # /usr/lib/jvm/jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file
>> /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot
>> VM not loaded
>> at
>> jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:115)
>> at
>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
>> at
>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
>>
>> / # ls -l /proc/1/cwd
>> ls: /proc/1/cwd: cannot read link: Permission denied
>> lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd
>>
>>
>>
>> After this change, we can see following exception on the console of jcmd
>> when we encounter this situation:
>>
>> # jcmd 1 VM.version
>> 1:
>> com.sun.tools.attach.AttachNotSupportedException: Unable to access the
>> filesystem of the target process
>> at jdk.attac...
>
> Yasumasa Suenaga has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Fix line
> - Update copyright year
I think we cannot remove `catch` for IOException because it is used for
fallback code.
I added numbers as comment to the code to explain:
try {
if (Files.isWritable(tmpOnProcPidRoot)) {
return tmpOnProcPidRoot.toString();
} else if (Files.isSameFile(tmpOnProcPidRoot, TMPDIR)) { // <- (1)
return TMPDIR.toString();
} else {
throw new AttachNotSupportedException("Unable to access the
filesystem of the target process"); // <- (2)
}
} catch (IOException ioe) {
try {
boolean found = MonitoredHost.getMonitoredHost("//localhost")
.activeVms()
.stream()
.anyMatch(i -> pid ==
i.intValue());
if (found) {
// We can use /tmp because target process is on same host
// even if we cannot access /proc/<PID>/root.
// The process with capsh/setcap would fall this pattern.
return TMPDIR.toString();
}
// Throw original IOE if target process not found on localhost.
throw ioe; // <- (3)
} catch (MonitorException | URISyntaxException e) { // <- (4)
// Other exceptions (happened at MonitoredHost) would be
wrapped with AttachNotSupportedException
throw new AttachNotSupportedException("Unable to find target
proces", e);
}
}
1. AccessDeniedException might be thrown if the process is not granted to
access the path. In addition, other exceptions which inherits IOException would
be thrown I/O error (e.g. disconnection of network file system)
2. If `/proc/<pid>/root/tmp` is not writable and it is different from `/tmp`,
AttachNotSupportedException is thrown. It would be happened in container, or
jailed process (chroot). I think that target process can be considered to be
running in an environment that does not support Attach API.
3. If IOException is happened at `Files.isSame()`, Attach API attempts to check
whether target process (PID) is listed in active VMs in `MonitoredHost`. Throws
original IOException if not.
4. Methods in `MonitoredHost` might throw `MonitorException` or
`URISyntaxException`.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3767711293
